RIB Self-Service Enablement

4 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 4-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. Example shown for rib-ext for dropping messages for specific types for subscriptions. Similarly, the drop messages types can be configured for other RIB applications like rib-sim, rib-rms and so on. Note: There are other infrastructure level options that are available only for AMS or devops teams to configure or update, as shown in the screenshot.
Email notification fields are read only now which means email notification configuration can’t be altered post provisioning. If customer wants to enable email notification or update configuration then this request has to come through proper channel and can be done from backend.
Provisioning Injector Service URL Hook to alternate subscribing retail application installation. Injector service url can be updated only for customer owned apps like -rib-ext , rib-lgf
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.

By default , dynamic adapter selection feature is enabled for rib-ext. enableDynamicAdapterInstanceSelection flag is applicable ONLY for RIB-EXT and this flag shouldn't be used in any other rib-apps.
```
enableDynamicAdapterInstanceSelection=true
```
Only if the above property is set to true, the user can select the adapters dynamically. Below is the default landing page when RIB adapters added in scope.
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.

Verify that the selected adapters are reflected on the Adapter Manager tab. Newly added adapters in scope will be down. Newly added adapters in-scope need a start from the GUI to become ACTIVE as a one time activity; otherwise, newly added adapters won’t show up on topic on checking from jms-console and won’t even be registered (messages will be lost). Sometimes you need to start adapters 2-3 times because of one known issue where the subscriber registration process is times out. Post start of newly added adapters, ensure adapters are showing up on topic on checking from jms-console. If newly added adapters are not showing up on topic, please try to start them again from the UI. jms-console will not show adapters on topic immediately and there is expected 3 to 5 mins of delay.
All the adapters are in scope by default for rib-<app>:
```
enableDynamicAdapterInstanceSelection = false
```
This is the default value for all rib-<app>s except rib-ext for rib-ext following flag is set to true
```
enableDynamicAdapterInstanceSelection = true
```
Note:
enableDynamicAdapterInstanceSelection flag is not available for end user update. Follow the steps in the next section to disable this flag for other rib-<apps> in case they are enabled.

How to Remove Dynamic Adapters Selection in RIB-RMS

The concept of Dynamic Adapters Selection applies only to the RIB-EXT application and all other RIB-<apps> such as RIB-RMS, RIB-SIM, RIB-TAFR etc do not support the dynamic adapters. Due to our documentation defect, which has been fixed now, some of our customers have used this feature in non RIB-EXT apps, especially in RIB-RMS, which is unsupported and can cause major issues such as messages piling up on JMS topics and slow down the entire system. customers should remove dynamic selection of the adapters in any rib-app they might have configured it in ex: RIB-RMS/RIB-TAF/RIB-SIM

Steps :

Log into the RIB-RMS Admin GUI.
Go to the Adapter Manager page and capture the list of adapters present on the page.
Go to Manage Configurations -> Adapter Selection and select all the adapters.
Click Save. Make sure all the adapters are displayed in the Adapter Manager page.
Go to Manage Configurations -> System Options and set enableDynamicAdapterInstanceSelection to false.
Go to the Adapter Manager page and bring down all the adapters that do not belong to the list collected in step 2.

Provisioning System Options

Application specific properties for the rib-<app> are configured in the rib.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. There are some infrastructure level options that are available only for AMS or devops teams to configure or update.

Following are the frequently configurable RIB properties:

Drop-messages-of-types- for dropping messages for specific types for subscriptions.
Updating facility_id and facility_type for rib-tafr.
A new system option can also be added using 'Add' functionality in UI. Perform the following steps to add the Facilities for rib-tafr.
- Click the Add button.
- Insert a new Facility ID.
  
  For example: key - facility_id.PROD.12345 value - 1
Updating injector service url and policy for rest-app.
Updating IDCS host URL. This is needed only for customer owned applications using Oauth for rest call.

Provisioning InjectorService URL

In the RIB-Admin GUI, the Manage Configuration > Injector Service page allows the user to configure an injector service URL for a customer-owned applications.

Update injector service URL details by providing new host and port details and the user credentials for 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.