With the connection successfully created and tested, we can start creating the integration. So, once we have navigated to the Integrations of the designer, we need to click on New Integration and select the Basic Map Data pattern. We can then define the integration as follows:
|
Property |
Description |
|
Integration Name |
|
|
Identifier |
This will be proposed based on the connection name, and there is no need to change it unless you would like an alternate name. |
|
Version |
01.00.0000 |
|
Package Name |
|
|
Description |
|
With this complete, we can see the integration canvas. Locate the MessagingCloud_Ch8 connection and drag and drop it on to the Trigger pad. This will launch the wizard for defining the message queue to receive messages on. The wizard, in many ways, will be a lot like the REST definition, as we need to describe the queue to receive from and the message payload, so that structure can be applied.
We can use the following details to complete the configuration:
|
Tab |
Question |
Action |
|
Basic Info |
Call your endpoint field? |
To keep it simple, call it |
|
What does this end point do? |
Add the description: |
You should have a screen that looks something like the following:
Click on the Next button, so we can configure the next Operations tab, which will look something like the following screenshot:
We can complete this tab using the following details:
|
Tab |
Field |
Action |
|
Oracle Messaging Cloud Service |
Destination Name Filter |
A messaging service can be significantly populated with both queues and topics, therefore we can filter this down using the connection type (select Queue) and then by part of the name. |
|
Select Destination |
With the list of options reduced, the option of our inbound queue ( The content of the list is derived from part of the naming service (JNDI) information provided by the underlying application server. This does mean that other unexpected services might appear here. | |
|
Filter the Messages to Receive |
This provides the means to filter messages down using elements in the JMS header. As we have elected not to use this we can leave this empty. In complex environments with a shared queue it is possible to filter down what is received-for example, by the header containing a recipient Id. So each recipient connected to the queue could then apply a filter for just their IDs. Information on the syntax of a selector can be found at http://docs.oracle.com/javaee/6/api/javax/jms/Message.html | |
|
Continue to receive messages when offline |
This is only applicable to Topics, as it declares the subscription as durable, so if we lose contact with OMCS then it will hold messages for ICS when connectivity is recovered. For this to work, OMCS needs an identifier for each subscriber so it can determine which messages need to still be consumed once connectivity is re-established. | |
|
SubscriberID |
If we want a durable subscription this value needs to be set. As durability is not an issue in our example this can be left unmodified. |
Note
Additional information about selectors can be obtained from the following.
The syntax for message selector criteria is aligned to SQL 92 specification, which can be found at: http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt,
More information on JMS selectors can be seen at: http://docs.oracle.com/javaee/6/api/javax/jms/Message.html
The expressions limited to 255 characters and standard JMS header attributes are defined at: https://docs.oracle.com/cd/E19798-01/821-1841/bnces/index.html
Once this is complete, we have completed all the connectivity information and we can move on as usual by clicking the Next button. The next tab describes how to handle the messages, and looks like the following screenshot:
For our use case, we should configure the tab using the following details:
|
Tab |
Field |
Action |
|
Oracle Messaging Cloud Service Message |
Specify a definition for the message |
We want to use a schema to provide structure to the message-so set this as ticked. |
|
Provide a location to the XSD that describes your message |
Select Choose File and browse to where the chapter resources are and select the By providing a schema, we are telling ICS that we expect the message payload to comply to this structure. | |
|
Select the schema element to use in this integration |
For the trigger, we want to use |
With these details provided, we can click the Next button to see the Summary tab. The Summary tab should represent the details provided. With that we can complete the wizard by clicking on the Done button.
With this, we can now define the invoke end of the integration. As we have defined our connection as both Trigger and Invoke, we can drag and drop the MessageCloud_Ch8 connection onto the Invoke pad. We can then complete the definition with the following details:
|
Property |
Sub-property |
Description |
|
Basic Info |
Call your endpoint field? |
To keep it simple, call it |
|
What does this end point do? |
Add the description: | |
|
Oracle Messaging Cloud Service |
Destination Name Filter |
A messaging service can be significantly populated with different queues and topics, therefore we can filter this down using the connection type (select Queue) and then by part of the name. |
|
Select Destination |
With the list of options reduced, the option of our inbound queue should be easy to select-so select | |
|
Remove Message after 0 seconds |
It is possible to limit the amount of time that a message may reside on OMCS before the message is then removed from the queue. This can be used if the message has a limited period of meaning and is not transactionally sensitive. In our case, we do not want messages lingering on the queue for the maximum 14 days. So set the value to 600 seconds (10 minutes). |
This section, once complete, should look like the following screenshot:
With the connectivity aspects complete on the wizard, click on Done to define the payload aspects, using the following values:
|
Property |
Sub-property |
Description |
|
Oracle Messaging Cloud Service |
Specify a definition for the message |
We want to use a schema to provide structure to the message-so set this checkbox. |
|
Provide a location to the XSD that describes your message |
Select the Upload File and browse to where the chapter resources are and select the | |
|
Select the schema element to use in this integration |
For the invoke, we want to use |
With these values applied, we can click on the Next button that will move us to the Summary tab, which should reflect the values provided. We can click on the Done button to conclude configuring the target connection.
With the endpoints defined, we have two remaining steps-mapping the data so that the source and target data is manipulated and passed on, and configuring the tracking so that the information can be recorded during testing.
Select the mapping icon on the canvas, and use the following table to configure the mapping, as follows:
|
Source |
Target |
|
|
|
As the target only has one element that allows us to identify the update, we can provide simple linking and then close the mapper by clicking on Save and Exit Mapper.
To set up the tracking, click on the Tracking button and set the tracking to just use the pathID element. With that done, click on Done. On returning back to the integration, we should see something like the following screenshot:
Click on Save and then Exit Integration. We can activate this integration ready for testing.