Connectivity
Inbound connectivity acts as a bridge from external messaging endpoints to the solution gateway. Outbound connectivity is the mechanism by which events can be delivered from a solution. There is no programmatic equivalent of the gateway for outbound events.
To begin modeling connectivity, you must create a connectivity definitions file in your solution project. You define the bindings and external endpoints for your solution, along with any classifications and transformations you might need. To test connectivity, you must take the following actions before you submit events to your solution.
- Deploy the solution.
- Generate a solution configuration file.
- Complete the template entries for each endpoint in the configuration file.
Inbound connectivity
To define the inbound connectivity assets for your solution, create inbound bindings and endpoints in a connectivity definition (.cdef) file.
You can partition bindings and endpoints for your solution arbitrarily across multiple .cdef files that can share a common asset name space. An endpoint in one .cdef file can therefore reference a binding in another .cdef file. The names that you use for bindings and endpoints must be unique if they belong to the same solution.
Decision Server Insights uses inbound bindings for inbound JMS messages or XML messages over HTTP. The inbound binding identifies the format and protocol of inbound messages, and must reference an inbound endpoint. The inbound endpoint represents the source of the messages.
The following diagram shows four inbound endpoints and the bindings that they reference:
The following diagram shows the inbound XML messages that arrive over JMS, and the events that the messages produce.
If the format of an inbound message is not typed XML, which represents the model-specific XSD that is used by Insight Designer, then the solution connectivity file must specify an .xsl file to transform the content of the message into typed XML.
Decision Server Insights classifies inbound messages by testing them against an XPath expression. If the message matches the XPath expression, the message is transformed into an event. If the message does not match the XPath expression, the message is matched against subsequent classifiers. If the message does not match any of the classifiers, a specified alternative action occurs. The alternative action is to either discard the message, or to submit it to the runtime environment without transformation.
Outbound connectivity
To define the outbound connectivity assets for your solution, create outbound bindings and endpoints in a connectivity definition (.cdef) file.
You can partition bindings and endpoints for your solution arbitrarily across multiple .cdef files that can share a common asset name space. An endpoint in one .cdef file can therefore reference a binding in another .cdef file. The names that you use for bindings and endpoints must be unique if they belong to the same solution.
Decision Server Insights uses outbound bindings for sending outbound events in the form of serialized JMS or HTTP messages. The outbound binding determines which outbound events are sent, and determines the message format and protocol to be used. The outbound binding must reference an outbound endpoint that represents the destination for outbound JMS or HTTP messages. The destination is either a JMS connection factory and destination, or a URL.
The following figure shows how Decision Server Insights serializes events into outbound messages:
