| Oracle® Retail Service Backbone Oracle Retail Integration Console Guide 14.1 E57332-01 |
|
 Previous |
 Next |
| Oracle® Retail Service Backbone Oracle Retail Integration Console Guide 14.1 E57332-01 |
|
Previous |
Next |
All of the RSB, RIB, and DDI 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 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.
When a RIB flow is selected, the following additional panel is displayed.
This panel contains the Flow Diagram, its details 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.
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.
DDI Flow stands for Direct 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. DDI 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 DDI flows used in the retail environment.
DDI flows are not monitored or instrumented in the RSB environment. RIC shows the DDI 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 DDI integration flow information comes from a static XML file (ddi-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 DDI 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. Interface tables are generally de normalized flatter simpler tables designed to make interaction with external programs easier.
The Transporter Application receives the data from the interface tables of the Source Application, performs any required mapping or transformation and stores the data in the Interface tables 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 DDI flows can be filtered for viewing by selecting the menu By Flow Type --> DDI. You can also export the DDI flow list to a spreadsheet format. 
Each of the DDI 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 that takes data from the source application's interface table(s) and updates the destination application. 
The above diagram shows one of the DDI 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 program that updates 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.
