| Oracle® Retail Service Backbone Integration Console User Guide Release 19.0 F22955-02 |
|
 Previous |
 Next |
| Oracle® Retail Service Backbone Integration Console User Guide Release 19.0 F22955-02 |
|
Previous |
Next |
The RSB, RIB, and BDI integration flows are displayed in three different tables. The menu on the left side helps to filter the flow entries by App Name, Message Family Name, or Type of flow.
The table shows the following columns:
Flow ID: This is a unique ID assigned to each integration flow.
Consumer Application: The application that consumes the service.
Consumer: The qualified name of the consumer service.
Decorator: The name of the decorator service.
Provider: The qualified name of the provider service.
Provider Application: The name of the application that provides the service.
Family Name: The name of the message family of the service.
The table shows the following columns:
Flow ID: This is a unique ID assigned to each integration flow.
Publisher Application: The application that publishes the message to a topic.
Publisher: The qualified name of the publisher topic.
Subscriber: The qualified name of the subscriber topic.
Subscriber Application: The application that subscribes to the topic.
When a row in the table (RSB, BDI, or RIB) is selected, a panel appears below the table and gets populated with detailed information of the selected flow.
When an RSB flow is selected, four additional tabs are displayed.
This panel displays the diagram of request flow from consumer, decorator service and provider in sequence.
This table shows three graphs of collected metric information.
This graph displays the number of success and failure counts for decorator and Edge App Service.
This tab has 3 additional sub-tabs that display the Decorator Service SLA alerts, Edge App SLA Alerts and Decorator Service Business alerts.
These are generated when the decorator service violates the service level agreement or a predefined condition.
This tab displays a table of the following columns:
Component: The components that are secured in the flow.
Edge Application Service: The retail application in RIB. For example, RMS.
Proxy Service and Business Service: RSB components in OSB.
Consumer: The retail application that is either internal or external.
Name: The names of the components used in the flow.
Policy Type: This is the name of the web service policy configuration. Possible values are:
PolicyUnsecured
PolicyA
PolicyB
|
Note: The security policies certified by Oracle Retail are:
|
Policy Name: The policy security configuration used to secure the component.
For Policy A, the Policy Name is Wssp1.2-2007-Https-UsernameToken-Plain.xml.
For Policy B, the Policy Name is Wssp1.2-2007-Wss1.1-UsernameToken-Plain-EncryptedKey-Basic128.xml, Wssp1.2-2007-EncryptBody and Wssp1.2-2007-SignBody.xml.
Is Certified?: Displays whether the security policy is supported.
|
Note: See the Oracle Retail Service Backbone Security Guide for more details. |
When a RIB flow is selected, the following additional panel is displayed.
This panel contains the two tabs: Flow Details and Metrics Graph.
This tab shows the Flow Diagram, its details, adapter status, JMS subscriber activity, error hospital activity and the Family, Message, and Payload information table.
Flow Diagram displays the diagram of request flow from publisher, topic (or TAFR) and subscriber in sequence.
Publisher is responsible for creating the messages.
Topic is where the publisher publishes its messages to.
TAFR is a RIB component that could transform, filter and route the message.
Subscriber receives the message.
RIB Adapter Status: This table displays the status of the adapters participating in the selected flow.
JMS Subscriber Activity: This table displays the messages waiting and messages processed for the JMS topic participating in the selected flow.
Error Hospital Activity: This table displays the family, total, and dependent messages in error hospital, for the adapters participating in the flow.
Family, Message and Payload Information: This table displays the family, message, and payload information for the selected message flow:Message Family: Contains information specific to a related set of operations on a business entity or related business entities. For example, Order message family contains information about purchase order events.Message Type: A message family may contain multiple message types. Each message type encapsulates the information specific to a business entity within one or more business events. For example, the order message family is published for events such as Delete PO, Create PO.Payload Information: the Retail Business Object (RBO) type for the Message Type.
Application API Information: Each PL/SQL based application uses a Message Family Manager specific API for publishing all messages within a specific message family. API is an interface to stored procedure package and wrapper to the staging table and additional business logic surrounding the message publication.
This tab shows adapter activity, min, max and arithmetic mean processing time and total commit vs error count for each adapter participating in this flow.
Adapter Activity: This table displays the total event count and last processing time for all the adapters participating in the selected flow.
Min, Max, and Arithmetic Mean processing time for each adapter participating in this flow: This bar graph shows the minimum, maximum and arithmetic mean processing time statistics for each adapter participating in the selected flow.
Total Commit vs Error Count for each adapter participating in this flow: This bar graph shows the total commit and error count comparison for each adapter participating in the selected flow.
|
Note: See the Oracle Retail Integration Bus Implementation Guide for more details. |
BDI Flow stands for Bulk Data Integration Flow. These flows represent a third type of integration in Retail applications. The message oriented asynchronous flows are represented by the RIB message flows while the service oriented synchronous flows are represented by the RSB message flows. BDI represents batch oriented bulk data integration flows in Retail application eco-system.
Previously, RIC showed only the RIB message flows and RSB service flows. With this release, RIC displays the BDI flows used in the retail environment.
BDI flows are not monitored or instrumented in the RSB environment. RIC shows the BDI flows in Retail applications for informational purposes only. Also, not every batch or bulk integration is shown in the RIC. There could be other functional batch integrations that are not shown in the RIC.
The BDI integration flow information comes from a static XML file (bdi-integration-flows.xml) in the rsb-home. During the RSB compilation step, the information in this file is used to create the diagrams and other details shown in the RIC.
A generic BDI flow can be represented by the following diagram:
The Source Application provides the data. There may be an exporter program(s) in the source application that extracts the business data from the transactional tables and updates the interface tables in the integration schema. Interface tables are generally de normalized flatter simpler tables designed to make interaction with external programs easier.
The Transporter Application receives the data of the source application from the interface tables in integration schema and loads the data to the Interface tables in the integration schema of the Destination Application. During this time, it may use intermediate storage, like flat files.
The Destination Application is the consumer of the data. There may be an importer program in the Destination Application that takes data from the interface tables, runs through the validation code, executes the business logic process, and finally updates the data in the transaction tables.
In RIC, the BDI flows can be filtered for viewing by selecting the menu By Flow Type --> BDI. You can also export the BDI flow list to a spreadsheet format.
Each of the BDI flows is given a unique Flow ID. The Source Application Name is the name of the application that acts as the source of data and the Destination Application Name is the name of the application that consumes the data. The Transporter is the intermediate application (batch job) that takes data from the source application's interface table(s) and updates the destination application.
The above diagram shows one of the BDI flows in the Retail system.
Source Application Name: The application that acts as the source of data. In this case, it is the RMS.
Exporter Program Name: In this case, the Transporter is taking the data directly from the source system tables. Since there is no program in the source system that takes data from the application tables and updates the staging tables, the Exporter Program Name is shown as NONE.
Interfaces Tables: The Transporter sources data from these tables.
Transporter Application Name: The application that owns and executes the Transporter Program.
Transporter Program Name: It is the batch job program that transmits data from the source interface tables to the interface tables of the Destination Application.
Intermediate Files: These are the names of flat files created by the Transporter program.
Destination Application Name: This is the name of the consumer application.
Importer Program Name: The name of the program that takes the data from the Interface tables and updates the transaction tables.
Interface Tables: These are the interface table(s) in the destination application.
