The fireside chat from a Cisco executive on SONA addresses a FAQ on AON devices's programming environment. If you have the time, I assure you this 1 hr+ presentation is worth the time.
As the presenter points out, AON devices are not programmed in the same way as the server side cousins. There is no IDE, SDK or APIs. The fundamental task of an AON device is to find the destination service and route the message to that service and perform any intermediary tasks that can be in done in the network. This message path is programmed rather differently than a server side implementation. For example, a message path which simply accepts a message from a synchronous http channel and dispatches that message to an SMTP channel would look like this.
[from-http-sync]
Match => "SomePatternInAnyGrammar", WithThisPriority#, RunSomeProcessing
Catch => "ForTheSamePattern", ThisException, RunThisExceptionHandler
Include => SomeOtherContext, WithTheseConditions
Dispatch (TransformedMessage, OnThisChannel)
These simple context can be combined to form a larger context which defines the message path. On the CLI one can easily verify that this rule is turned on by
CLI> show context from-http-sync
[from-http-sync created by ...]
'Pattern'
1. SomeProcessing
2. Included Processing steps of another context
3. Dispatch to SMTP
Wednesday, January 04, 2006
Subscribe to:
Posts (Atom)
AI IDEs - Do you need it?
AI generated code IDEs like Replit, Cursor.sh and plugins into vscode are all the rage now a days. I blogged earlier on using continue.dev ...
