8 RIB Self-Service Enablement

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.
RIB ServiceMonitor Verify InjectorService provisioned in previous step.

Provisioning RIB-Adapters

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-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. Surrounding text describes rib_adapters_selected.png.

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.

Provisioning System Options

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.

Surrounding text describes rib_system_options_1.png.

Provisioning InjectorService URL

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 page 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.

Surrounding text describes rib_injector_service_1.png.

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.

RIB ServiceMonitor

Once the RIB integration environment is configured for use by various retail application, as a sanity test the user may need to verify the integration end points. For RIB on cloud, we can ping-test various webservices consumed by RIB using RIB admin GUI.

In RIB Admin GUI, the RibServiceMonitor page lists all the webservices consumed by the rib-application and allows the user to ping the same. The webservices are pingable only if the "ping" operation is supported by the webservice. Also the user can access the WSDL of these webservices. Below figure explains the same.

Surrounding text describes rib_servicemonitor2.png.

This page can be used to test the provisioning of InjectorService URL. Only RIBAdmin and RIBOperator users allowed to access the page.