Article originally published on the Oracle Integration Blog.
Broadcasting, Publish/Subscribe, Distributed Messaging, One-to-many, these are just some of the names referring to the same integration pattern, which is one of the most powerful available for connecting multiple systems.In a nutshell, this pattern is about:
- Source System publishes a message
- Target Systems subscribe to receiving that message
This enables the propagation of that message into all the target systems that subscribe to it, as illustrated in the below picture.
This pattern is not new, in fact, it’s been around for decades. It powered distributed systems with its inherent loose coupling and independence. Publishers and subscribers are loosely coupled which allows for the systems to run independently of each other. In the traditional client-server architecture, a client cannot send a message to a server that is offline. In the Pub/Sub model, message delivery is not conditioned by the server availability.
Topics VS Queues
The difference between a Topic and a Queue is that all subscribers to a Topic receive the same message when the message is published and only one subscriber to a Queue receives a message when the message is sent. This pattern is about Topics.
The Hard way
From a vendor neutral point of view, if an Organization needs a messaging infrastructure, it will typically need to setup hardware, install the OS and the messaging software, take care of configurations, creating and managing user, groups, roles, queues and topics…and this is only for the Development environment. Then we have Test and Production, which may require an HA cluster…you can see the direction this is going, it adds complexity.
The Easy way
Fortunately, OIC abstracts that complexity from the user. It’s Oracle managed, the Topics are created and managed by Oracle. From an integration developer point of view – the only requirement is to make use of the “ICS Messaging Service Adapter” – as we will explain in a bit.This brings the benefits of messaging to those that did not require the full extent of capabilities that a messaging infrastructure provides and were typically put away due to its complexity.
Use Cases
There are plenty of uses cases that would benefit from this solution pattern:
- User changes address data in the HCM application
- New contact/account created in the Sales or Marketing applications
- ERP Purchase Orders need to be shared downstream
Oracle’s OIC Adapters support many of the SaaS Business Events. How to enable that has been described in another blog entry: https://blogs.oracle.com/imc/subscribe-to-business-events-in- fusion-based-saas-applications-from-oracle-integration-cloud-oic-part-2
Implement in 4 Steps
For this use case, we will just use a REST request as the Publisher.
1. Create a REST trigger
Go to Connections and create a new one. Select the REST Adapter.
Provide a Name and a Description. The role should be Trigger. Press Create. Then you can save and close.
2. Create an Integration.
We will select the Type Publish To OIC, which provides the required structure.
Provide a name a description and optionally associate this integration with a package.
Now we can drag the connection we created before, from the pallet on the right side, into the Trigger area on the canvas (left side)The REST wizard pops up. We can add a name and a description.
The endpoint URI is /message – that’s the only parameter we need. We want to send a message; therefore the action is POST.
Select the Checkbox for “Configure a request payload for this request”. Leave everything else as default.
The payload format we want is JSON and we can insert inline a sample – as seen in the picture.
That’s all for the REST adapter configuration!
You should also add a tracking identifier.
The only available is the message element.
3. Activate the Integration.
We are now ready to activate the Integration. You can choose to enable tracing and payload for debugging. (Your activation window might look a bit different, as this has the API Platform CS integrated for API publishing)
4. Test the Integration.
After activation, you see a green banner on top of your screen with the endpoint metadata. Here you can find the endpoint URL to test the REST trigger we just created.Using Postman (or any other equivalent product) we can send a REST request containing the message we wish to broadcast.
And when we check the Tracking Instances under Monitoring…voilà, we see the instance of the Integration we just created.
And here we have the confirmation that the payload was sent to the Topic!
In Part 2 of this blog series we cover the Subscribers!