Oracle® Retail Integration Bus Implementation Guide Release 16.0.027 E96514-01 |
|
Previous |
Next |
The Self-service enablement is a feature for provisioning RIB on cloud post deployment only. Because of the promising high availability feature of applications on the cloud environment, this is an essential feature that minimizes the redo of the RIB install cycle post configuration changes to any RIB-app.
The Self-service enablement allows below provisioning in rib-<app>:
Table 8-1 Self-Service Feature
Self-Service Feature: | Self Service Feature on RIB-Admin GUI |
---|---|
Provisioning RIB adapters Choosing the subset of RIB adapters in scope for integration |
|
Provisioning System Options Dynamically modifying configurations via, rib-<app> properties file. |
|
Provisioning Injector Service URL Hook to alternate subscribing retail application installation. |
Every rib-<app> contains a set of publish and subscribing adapters for exchanging messages between retail applications. Subscribing adapters are MDB which are resource intensive. The higher the number of adapters in scope the higher is the resource crunch. In an environment which does not make use of all the publishing and subscribing adapters bundled with the rib-app, the user is allowed to choose a subset of the adapters needed based on the RIB functional flow. This configuration change takes effect dynamically and does not require a redeployment of the rib-<app>.
Follow the steps below for configuring the rib-<app> adapters in scope of the integration.
For every rib-<app> that needs a dynamic adapter selection to be enabled, add the property below in the rib-<app>. properties file before deploying the app.
enableDynamicAdapterInstanceSelection=true
Only if the above property is set to true, the user can select the adapters dynamically. By default, there are no rib-adapters in scope of integration.
In the RIB-Admin GUI, the Manage Configuration > Adapter Selection tab provides the list of all available adapters whose subset can be chosen to publish, subscribe and retry rib messages based on rib integration flows.
Select the subset of publishing, subscribing and retry adapters depending on the rib-integration-flow in consideration and click Save.
Consider the below rib-integration flows:
rib-sim publishing the InvReq message
<message-flow id="31"> <node id="rib-sim.InvReq_pub" app-name="rib-sim" adapter-class-def="InvReq_pub" type="DbToJms"> <in-db>default</in-db> <out-topic>etInvReq</out-topic> </node> <node id="rib-ext.InvReq_pub" app-name="rib-ext" adapter-class-def="InvReq_pub" type="DbToJms"> <in-db>default</in-db> <out-topic>etInvReq</out-topic> </node> <node id="rib-rms.InvReq_sub" app-name="rib-rms" adapter-class-def="InvReq_sub" type="JmsToDb"> <in-topic>etInvReq</in-topic> <out-db>default</out-db> </node> <node id="rib-ext.InvReq_sub" app-name="rib-ext" adapter-class-def="InvReq_sub" type="JmsToDb"> <in-topic>etInvReq</in-topic> <out-db>default</out-db> </node> </message-flow>
rib-sim subscribing the ItemLoc message from RMS
<message-flow id="6"> <node id="rib-rms.ItemLoc_pub" app-name="rib-rms" adapter-class-def="ItemLoc_pub" type="DbToJms"> <in-db>default</in-db> <out-topic>etItemLocFromRMS</out-topic> </node> <node id="rib-ext.ItemLoc_pub" app-name="rib-ext" adapter-class-def="ItemLoc_pub" type="DbToJms"> <in-db>default</in-db> <out-topic>etItemLocFromRMS</out-topic> </node> <node id="rib-sim.ItemLoc_sub" app-name="rib-sim" adapter-class-def="ItemLoc_sub" type="JmsToDb"> <in-topic>etItemLocFromRMS</in-topic> <out-db>default</out-db> </node> <node id="rib-rwms.ItemLoc_sub" app-name="rib-rwms" adapter-class-def="ItemLoc_sub" type="JmsToDb"> <in-topic>etItemLocFromRMS</in-topic> <out-db>default</out-db> </node> <node id="rib-rxm.ItemLoc_sub" app-name="rib-rxm" adapter-class-def="ItemLoc_sub" type="JmsToDb"> <in-topic>etItemLocFromRMS</in-topic> <out-db>default</out-db> </node> <node id="rib-ext.ItemLoc_sub" app-name="rib-ext" adapter-class-def="ItemLoc_sub" type="JmsToDb"> <in-topic>etItemLocFromRMS</in-topic> <out-db>default</out-db> </node> </message-flow>
Considering the above flows, select InvReq_Pub, and ItemLoc_sub and both Hospital adapters as shown in the image below.
Verify that the selected adapters are reflected on the Adapter Manager tab and are up and running.
Once the subset of adapters chosen for integration are saved, they cannot be undone.
To have all the adapters for rib-<app> in scope by default, set the property as follows:
enableDynamicAdapterInstanceSelection = false
This is the default value for all rib-<app>s except rib-ext.
Application specific properties for the rib-<app> are configured in the rib-<app>. properties file. When RIB is deployed on cloud, the application specific properties can be configured in the RIB-Admin GUI application. The Manage Configuration > System Options tab allows the user to edit the properties values post deployment.
The Oracle Retail application residing on-premise should be deployed as a soap-app to subscribe the messages from RIB on cloud. RIB subscribing adapters call the Injector Service hosted by the on-premise retail application to inject the messages into the retail application database.
In the RIB-Admin GUI, the Manage Configuration > Injector Service tab allows the admin user to configure a different injector service URL than the one configured during the deployment. RIB dynamically updates the subscribing adapters to send the messages using the injector service. This injector service URL should be secured, by using policyA or policyC. This secured user, with which the service is secured should belong to the IntegrationGroup in myrealm of the retail application's weblogic domain.
The admin user can edit the existing injector service URL details by providing new host and port details. The user also has to configure the security policy with which the new service configured is secured with, and the user credentials for RIB invoking the service.