Search Tips
The content and purpose of each message is irrelevant to the higher layers (Adapter and Workflow Engine). Once an adapter has been built, and connected to the Workflow Engine, application programmers can use it as a channel to transmit any appropriate application messages from system to system.
The CMiC software sits inside the white rectangle in the graphic above.
The Application Layer receives message events from a Receive Adapter and processes the message according to the rules of the application, possibly handing off a new message to the Transmit Adapter as a result of the processing.
The Application Layer can also hand off new messages to the Transmit Adapter as a result of application-specific event triggers (such as the creation of a new object in the database).
The Transmit Adapters encode message payloads into the appropriate formats depending on the communication protocol and style that is expected by the remote system.
The Receive Adapters decode message payloads from the CMiC published message formats based on the communication protocol and style of the Receive Adapter.
The Basics of Data Transmission: Select, Insert, Update, & Delete
The Http-Receive Adapter for CMiC software supports four basic operations: select, insert, update, and delete.
Data objects that are exposed by the adapter for transmission are called “resources”. Two types of resources can be accessed: collections and individual objects.
Collections are accessed via “<object_plural_name>_list”.
Individual objects are accessed via “<object_name>”.
Requests are sent to http://<server>:<port>/<cmic_environment>/wsrti/v1. The path /wsrti is the root entry into the adapters.
The version number is provided to allow us to support external systems that transmit messages to us using different versions of our adapter interface.
For example, two CMiC customers could be using RTI adapters to communicate messages between their systems. Initially, they both use our v1 adapters. Then one of them upgrades to a new version of our software which includes v1 and v2 adapters. The adapters in the new release must be able to understand messages from the external system which still only knows how to transmit v1 messages.
For example, if we provided two data objects called “departments” and “employees”, the following illustrates how any external system would perform select, insert, update, and delete operations through the http receive adapter running on a local system.
This section of the document uses the term URL and URI. Here we will provide a brief description of these two terms.
A URL is the request string typed into a browser address bar. For example, a URL might be http://www.oracle.com.
A URL is a Universal Resource Locator.
The format for a URL is: <protocol>://<server>:<port>/<URI>.
The beginning part of the URL identifies what protocol is being used, and where the resource that is being requested is located.
Everything after the <protocol>://<server>:<port>/ is the URI portion.
A URI is a Universal Resource Indicator. It is the portion of the URL that uniquely identifies a specific resource at the location <server>:<port>, using protocol <protocol>.
The CMiC RTI <protocol> is always http.
Most of the work done by the receive adapter is to parse out and understand the URI portion of each URL in a request.
Similarly, the work done by the transmit adapter is to form a valid URI for the URL request that it will transmit.
Key Values
CMiC will provide a published API for each resource identifying the key value or values that must be provided in order to uniquely identify each specific resource.
There is one set of key fields that are provided for every resource (i.e. one path to directly address every specific resource in the collection). In some cases, the key consists of an individual field. In other cases, the key is formed from a combination of fields.
Each request that requires key values must specify a value for every key field. Partial key requests are not permitted.
Key values are required for every UPDATE and DELETE request. UPDATE and DELETE requests always operate on specific resources. SELECT requests can select a specific resource or a collection resource.