| Oracle® Retail Omnichannel Cloud Data Service Implementation Guide Release 19.0.0 F25864-01 |
|
 Previous |
 Next |
| Oracle® Retail Omnichannel Cloud Data Service Implementation Guide Release 19.0.0 F25864-01 |
|
Previous |
Next |
This chapter deals with the technical design of OCDS.
The diagram below illustrates the basic deployment topology for OCDS. Alternatively, each OCDS component can be hosted in its own WebLogic Managed Server.
BDI-JA: OCDS (BDI) Job Admin is the interface between the Oracle Retail Bulk Data Integration and OCDS, enabling BDI data to flow into the OCDS database.
RIB-INJECTOR: OCDS (RIB) Injector is the interface between RIB infrastructure and OCDS; it listens for SOAP-based RIB messages containing incremental changes to data initially populated through BDI.
ORDS: The OCDS (ORDS) Web Service exposes the data managed by OCDS to Omnichannel applications.
Oracle provides many clustering solutions and options; those relevant to OCDS are Oracle database clusters and WebLogic Server clusters. Clustering directly addresses availability, scalability, recoverability requirements which are very attractive to a business. In reality though it is a tradeoff, a clustered system increases complexity, is normally more difficult to manage and secure, so one should evaluate the pros and cons before deciding to use clustering.
A WebLogic Server cluster consists of multiple WebLogic Server managed server instances running simultaneously and working together to provide increased scalability and reliability. A cluster appears to clients to be a single WebLogic Server instance. The server instances that constitute a cluster can run on the same machine, or be located on different machines. You can increase a cluster's capacity by adding additional server instances to the cluster on an existing machine, or you can add machines to the cluster to host the incremental server instances. Each server instance in a cluster must run the same version of WebLogic Server.
In an active-passive configuration, the passive components are only used when the active component fails. Active-passive solutions deploy an active instance that handles requests and a passive instance that is on standby. In addition, a heartbeat mechanism is usually set up between these two instances together with a hardware cluster (such as Sun Cluster, Veritas, RedHat Cluster Manager, and Oracle CRS) agent so that when the active instance fails, the agent shuts down the active instance completely, brings up the passive instance, and resumes application services. In an active-active model all equivalent members are active and none are on standby. All instances handle requests concurrently. An active-active system generally provides higher transparency to consumers and has a greater scalability than an active-passive system. On the other hand, the operational and licensing costs of an active-passive model are lower than that of an active-active deployment.
|
Note: See the Oracle® Fusion Middleware Using Clusters for Oracle WebLogic Server documentation for more information.
|
The OCDS BDI Job Admin is, in Oracle® Retail Bulk Data Integration terminology, a BDI edge application. BDI edge apps can be deployed into in an active-active cluster environment to achieve better throughput.
For more information see the Oracle® Retail Bulk Data Integration Implementation Guide.
The RIB Injector is a Web Service consumer of SOAP messages.
The RIB architecture is designed for active-passive clusters only, so there can only be one injector end points on the consuming side. However, through-put can be optimized by customizing the RIB's multi-channel feature that allows parallel threads to send messages to a consumer, such as OCDS. The producer-side can be setup with multiple channels; for example, there would be 10 subscriber adapters in play sending messages in parallel to the OCDS Injector end point. The # of channels can be configured and will typically match how fast the consuming application can consume the messages.
See chapter 10 of the Oracle® Retail Integration Bus Operations Guide for more information.
The ords.war file can be deployed onto more than one managed server. The ORDS configuration directories and files (stored in config/ords) must be made available on each managed server.
For more detailed information see Oracle REST Data Services Installation, Configuration, and Development Guide.
The OCDS database contains two distinct schemas, one serves as the interface to the Bulk Data Integration, the other contains the data served to OCDS web service clients.
Tablespaces are a collection of logical storage units in the database. The tablespace to schema association is determined by database administrators at install time.
Schema objects are the logical structures that directly refer to the database's data. Schema objects include structures like tables, procedures, and indexes.
Table 2-1 Schema Objects
| Type | Database User | Description |
|---|---|---|
|
BDI Interface |
ocds_ifc |
The database contains BDI Interface tables into which the Oracle Bulk Data Integration inserts Merchandising and Pricing data. The content of BDI Interface tables is only changed by BDI activity. |
|
OCDS Transactional |
ocds_txn |
The database contains transactional tables that function as a living snapshot of the latest Merchandising and Pricing data. The contents of Transactional tables are initially populated by BDI. In addition, Transactional tables are modified when incremental changes to Merchandising data are received from RIB messages. |
The transactional schema contains tables necessary for serving the Enterprise Data needs of Omnichannel applications. Most transactional tables are initially populated by BDI activity. In addition, many tables are modified by the contents of RIB messages.
Despite what this schema's name might suggest, the Transactional Schema does not contain any data retailers commonly refer to as "transaction data". In OCDS terms, the word "transactional" distinguishes how the contents of this schema's tables change frequently over time, as RIB messages are consumed and incremental BDI data, whereas the Interface Schema's table contents are a static snapshot of exported data from Merchandising and Pricing systems.
The core Transactional schema tables are initially populated as part of the inbound BDI flow managed by Job Admin. After BDI Interface tables are loaded successfully from BDI, a BDI "importer" copies data from Interface schema tables to Transactional schema tables.
The core Transactional schema tables contain, in many cases, only a subset of the columns of their corresponding table in the Interface schema. Only columns useful to Omnichannel applications are included in the Transactional schema's tables.
Transactional schema tables that contain data also communicated from RIB messages include the use of timestamp control columns. These columns are used by the OCDS web service API in calculating an "action" value. Action values provide a hint to the calling application how the data should be handled. Actions have values such as INSERT, UPSERT, UPDATE, and DELETE.
The timestamp control columns are:
The Transactional schema contains two diagnostic logging-related a tables: LOG_ENTRY and LOG_SEVERITY. The LOG_SEVERITY table can be used to turn on and off the ERROR, INFO and DEBUG log messages that can be written to the LOG_ENTRY table by OCDS database procedures in the transactional schema.
The interface schema contains all of the inbound-interface tables necessary for receiving Merchandising and Pricing data from the Bulk Data Integration (BDI) infrastructure. OCDS is a receiving-only BDI Edge Application. Up-stream BDI components have responsibility for sending data to OCDS, and into the interface schema.
