| Oracle® Retail POS Suite 14.1/Merchandising 14.1.1 Implementation Guide Release 14.1.1 E63051-02 |
|
 Previous |
 Next |
| Oracle® Retail POS Suite 14.1/Merchandising 14.1.1 Implementation Guide Release 14.1.1 E63051-02 |
|
Previous |
Next |
This chapter contains the following topics:
Data Import from Oracle Retail Merchandising System and Oracle Retail Price Management
Oracle Retail Price Management to Oracle Retail POS Suite Integration Overview
Oracle Retail Merchandising System to Oracle Retail POS Suite Integration Overview
Oracle Retail POS Suite to Oracle Retail Sales Audit Overview
Seed data such as item, price and tax must be updated on an ongoing basis in the Store database as well as Operational Data Store (ODS) to enable daily store operations. Typically the system of truth for such data is an enterprise system, such as Oracle Retail Merchandising System, Oracle Retail Price Management or a third-party product. The frequency and size of the data feeds varies from customer to customer. Imports are scheduled to be picked up by stores on a nightly basis. This interval is adjustable. See the section on spring.properties.
|
Note: Data Import (DIMP) is not the system of record for data correctness. All data coming into the data import module is assumed to be correct. This applies at two levels:
For example, there is no foreign key constraint enforced between the employee and store entities. A Kill And Fill import of the store hierarchy can result in a new set of stores that does not include a store for some existing employees. The external system that creates this import data must ensure that this type of situation does not occur. |
|
Note: The base DIMP modules support parsing XML files only. |
Figure 1-1 is an overview diagram of an integration of Oracle Retail POS Suite and Oracle Retail Merchandising System, including a Data Import logical flow:
The following process describes the flow of a generic data import:
The flow begins with the Quartz Scheduler configured in Spring invoking the ImportIOAdapter of the DIMP Controller module.
An import can be processed by either Central Office or Back Office. Central Office is not configured to processes Pricing imports. To get new data to a store, the data must be imported by Back Office.
The DIMP Controller picks up the import bundle, which is a compressed archive, and invokes the DIMP Translator.
The XML files are processed as input streams in the order specified in the manifest by DIMP translators: one for each import type:
Currency for Currency Import
Customer for Customer Import
Employee for Employee Import
Item for Item Import
Merchandise for Merchandise Hierarchy Import
Pricing for Pricing Import
ScanSheet for Scan Sheet Imprt
Store for Store Hierarchy Import
Tax for Tax Import
The implementation of the ImportTranslatorIfc (as configured by the Spring context) retrieves an instance of an ImportControllerIfc from Spring and creates a new ImportBatch.
The translator begins to parse its document and calls initializeImport onto the controller.
The translator sets the batch size based upon its configuration.
The translator then loops through the elements in the document, creating a Data Transfer Object (DTO) for each complex element. The entity DTOs are processed one at a time in the order they are placed into the ImportBatch, with all Delete DTOs processing first, all Add DTOs second, then all Update DTOs last.
The controller retrieves an instance of the specified Data Access Object (DAO) from Spring based upon the key passed to it and calls initializeImport() on the DAO.
The translator then loops through the elements in the document, creating a Data Transfer Object (DTO) as each complex element. The entity DTOs are processed one at a time by placing them into the batch.
Each batch is processed as a transaction. Any records in the batch with data errors roll back that transaction. The import proceeds with the next batch.
The default batch size is 1000. See spring.properties in Chapter 3 for more information.
The translator gives the ImportController a signal to process the batch after adding each DTO by calling processBatch().
If the batch size has been reached, the controller sends the batch to the DAO to be persisted.
The ImportDAOIfc loops through each DTO and delegates its data operation to a subordinate DAO.
Once the document parsing is complete, the translator notifies the controller, which processes the batch if there are any DTOs left over.
Finally, the controller calls completeImport() on the DAO, giving it the opportunity to copy data from temporary to production tables and drop temporary tables in case of a Kill And Fill, or release JDBC resources, and so forth.
|
Note: If you choose to retain any existing Oracle Retail Back Office or Oracle Retail Point-of-Service item-related functionality that creates or changes data types that are imported from Oracle Retail Merchandising System or any third-party merchandising systems, you are responsible for handling and addressing any data overwrites performed by the import process. |
There are three feed methods:
Temporary tables are created at the beginning of a file's processing. Batches are written to the temporary tables. If the entire file is processed without error (all batches), the temporary table data replaces the production data and the temporary tables are dropped. If an error occurs, it is logged and the entire file import is aborted.
|
Note: During the data import of any PricingImport that has had its FillType set to Kill And Fill, all tables that contain AdvancedPricingRules, PricePromotions, and PriceChanges are cleared and refilled with the new data that is imported only. The PriceLookup mechanism uses the PriceChange tables to calculate the current price of an item. If all the prices are not supplied for existing items during a PricingImport Kill And Fill, then the items without prices have values of zero. |
Full Incremental is a fill type that performs adds and update, expecting that all data attributes for a particular record are included in the XML element. Any missing attributes are set to default values. Replace operations still only require enough data to properly identify the record.
|
Note: All columns for a row must be present in the import data. |
For Full Incremental imports, each import XML data element must include all values. If some values are omitted from the import file, then the Data Import still updates the records in question, but uses default values for the omitted elements or attributes. Usually the default value chosen is null, zero or false unless otherwise specified in the XSD.
Consult the TablesMapping spreadsheets and the Data Dictionary for values to which specific columns are defaulted.
Delta Incremental is a fill type that produces dynamic update statements that allow for only those data attributes which are included in the file to be updated, leaving existing data attributes intact.
|
Note: Only those fields being updated are required in the import data. |
Files listed in the manifest without any dependency will be processed first in no particular order. Then those files whose dependencies have already been processed will be processed, until all are completed. The following dependency information dictates the order in which files can be processed:
Tax depends on nothing.
Store Hierarchy/Stores depends on Tax (GeoCode).
|
Note: Oracle Retail Price Management and Oracle Retail Merchandising System do not provide any tax information, such as Tax Geocodes for stores or TaxGroup IDs for items. It is the responsibility of the implementation team to intercept the following download data and use a third-party tax application to apply the appropriate tax information:
The implementation team must apply appropriate tax information after every Kill And Fill operation. This ensures that tax information applied to the store database is retained the next time a Kill And Fill operation is conducted. An alternate tax information option involves the use of database triggers. The implementation team can create a database trigger to repopulate the Store table in the database with hard-coded tax information after every Kill And Fill operation. The implementation team is responsible for implementing the database trigger and providing the hard-coded tax information. |
Employee depends on Store Hierarchy/Stores.
Merchandise Hierarchy depends on nothing.
Item depends on Tax and Merchandise Hierarchy.
|
Note: Oracle Retail Price Management and Oracle Retail Merchandising System do not provide Tax Geocodes for stores or TaxGroup IDs for items. It is the responsibility of the implementation team to intercept download data and use a third-party tax application to apply the appropriate tax information. |
Pricing depends on Item and Customer.
Currency depends on nothing.
Customer depends on nothing.
ScanSheet depends on Item.
Oracle Retail Price Management is a strategy-based pricing solution that suggests and assists with pricing decisions, yielding a more predictable and profitable outcome. Oracle Retail Price Management evaluates prices within a broad business context with real-time access to the following:
Competitive and market data
Projected sales impact
Margin
Pricing-based costs
Current and projected inventory positions
Markdown budgets
Oracle Retail Price Management provides a well-defined and efficient price change process that allows for aggregated permanent and clearance price change execution. Oracle Retail Price Management enables retailers to automate and streamline pricing strategies across the organization. Oracle Retail Price Management provides decision support to all pricing-focused business information to validate and approve pricing and markdown suggestions.
|
Note: This integration is one-way only. Oracle Retail POS Suite changes are not communicated back up to Oracle Retail Price Management. |
Figure 1-2 shows a high level overview of the integration.
Oracle Retail Merchandising System provides for core merchandising activities, including inventory replenishment, purchasing, and vendor management, in a global environment, across multiple retail channels. The solution incorporates three functional areas:
Business foundation management
Merchandise management
Merchandise financial tracking
These functional areas enable retailers to streamline their business systems and unify business practices across their organization.
Oracle Retail Merchandising System is the main application for item, item location, merchandise hierarchy, stores and store (organizational) hierarchy data. This data is necessary for store operations and must be updated in the stores on an ongoing basis. Further, this data, particularly item data, can range in size from small incremental updates to large batch loads. The frequency and size of data feeds varies widely from customer to customer.
|
Note: This integration is one-way only. Oracle Retail POS Suite changes are not communicated back up to Oracle Retail Merchandising System. |
|
Note: There are some conditions required on data in order to filter out the Oracle Retail Merchandising System data being extracted to the XML files. This is required mainly because Oracle Retail Point-of-Service has these limitations on data types. Some of these conditions are:
For more information, see Oracle Retail POS Suite Relational Integrity Diagrams. |
|
Note: In Oracle Retail Merchandising System, class-level and store-level VAT-inclusive indicators must be set based on the Oracle Retail Point-of-Service configuration:
|
Figure 1-3 shows a high level overview of the integration.
The integration of the Oracle Retail POS Suite products with Oracle Retail Sales Audit involves the following components:
The Oracle Retail POS Suite logical component is comprised of Oracle Retail Point-of-Service, Back Office, and Central Office. RTLog data is created from Point-of-Service.
The RTLog file is the communication mechanism for providing data from the Oracle Retail POS Suite to Oracle Retail Sales Audit. The RTLog is a transaction log file that is formatted specifically for Oracle Retail Sales Audit. Raw transaction data in the RTLog file is meant to update other merchandising system applications, and is populated from Oracle Retail POS Suite. The file is written to the physical file system by Oracle Retail POS Suite for consumption by the transportation middleware.
Oracle Retail POS Suite is responsible for writing the RTLog files to a configurable physical directory on the Store Server.
The propname="outputAdapterClassName" class in the StoreServerConduit.xml file controls the writing of the RTLog to a file.
Example 1-1 Sample excerpted from StoreServerConduit.xml (POS Suite RTLog Files)
<TECHNICIAN name="RTLogExportDaemonTechnician" class="RTLogExportDaemonTechnician" package="oracle.retail.stores.domain.manager.rtlog" export="Y"> <PROPERTY propname="daemonClassName" propvalue="oracle.retail.stores.domain.manager. rtlog.RTLogExportDaemonThread"/> <PROPERTY propname="daemonName" propvalue="RTLogExportDaemon"/> <PROPERTY propname="sleepInterval" propvalue="600"/> <PROPERTY propname="exportDirectoryName" propvalue="POSLog"/> <PROPERTY propname="databaseAdapterClassName" propvalue="oracle.retail.stores.domain.manager. rtlog.RTLogDatabaseAdapter"/> <PROPERTY propname="encryptionAdapterClassName" propvalue="oracle.retail.stores.domain.manager. rtlog.RTLogEncryptionAdapter"/> <PROPERTY propname="outputAdapterClassName" propvalue="oracle.retail.stores.exportfile.rtlog.RTLogClearTextOutputAdapter
Oracle Retail Sales Audit does not currently support the key store approach to decrypting RTLog files. As of the current release, it is the implementer's responsibility to enhance the decryption functionality in Oracle Retail Sales Audit.
The transport middleware is a component that is responsible for polling the RTLog file produced by the Oracle Retail POS Suite. This component has the following responsibilities:
Polling the physical file system at a specified directory.
Writing the RTLog file to a location thatOracle Retail Sales Audit expects.
Cleaning and archiving the RTLog file once Oracle Retail Sales Audit has consumed the RTLog file.
Error notification if the RTLog file is not able to be extracted successfully from a physical directory.
|
Note: Transport middleware is not provided by Oracle Retail. It is the responsibility of the implementation team to provide the integration middleware of their choice. |
Oracle Retail Sales Audit is the gateway for transaction data updates to Oracle Retail Merchandising System and Oracle Retail Store Inventory Management. Oracle Retail Sales Audit consumes the RTLog file written to a specific directory by the integration middleware. Oracle Retail Sales Audit also sends audited data files to other merchandising system applications for consumption.
The following figure depicts the two domains that are involved when integrating transaction data within the Oracle Retail suite.
The following preconditions must be observed for the system flow to function correctly:
Transport middleware requires read and write access to the physical file system to which Oracle Retail POS Suite writes the RTLog file.
Transport middleware requires read and write access to the physical file system from which Oracle Retail Sales Audit reads the RTLog files.
Oracle Retail POS Suite requires access to a physical file system to produce the RTLog file.
In Windows, the Point-of-Service store server runs from the C:\OracleRetailStore\Server\pos\bin directory. The propname="exportDirectoryName" property in the following example enables implementers to specify the complete path name of any pre-existing directory on the store server computer to which they want to write RTLogs.
Example 1-2 Sample excerpted from StoreServerConduit.xml (Changing RTLog Locations)
<TECHNICIAN name="RTLogExportDaemonTechnician"
class="RTLogExportDaemonTechnician"
package="oracle.retail.stores.domain.manager.rtlog"
export="Y">
<PROPERTY propname="daemonClassName"
propvalue="oracle.retail.stores.domain.manager.rtlog.RTLogExportDaemonThread"/>
<PROPERTY propname="daemonName"
propvalue="RTLogExportDaemon"/>
<PROPERTY propname="sleepInterval"
propvalue="600"/>
<PROPERTY propname="exportDirectoryName"
propvalue="POSLog"/>
The value propvalue="POSLog"/> indicates that the RTLog files will be written to the relative path POSLog, or the complete pathname C:\OracleRetailStore\Server\pos\bin\POSLog.
The Point-of-Service client application generates transaction data and sends the transaction object structure to the Point-of-Service store server. The Point-of-Service store server populates the JDBC statement type and commits the transaction data to the store database. The time increment at which data is sent to Oracle Retail Sales Audit is dictated by the retailer by editing the propname="sleepInterval" property in the StoreServerConduit.xml file:
Example 1-3 Sample excerpted from StoreServerConduit.xml (System Flow Description)
<TECHNICIAN name="RTLogExportDaemonTechnician"
class="RTLogExportDaemonTechnician"
package="oracle.retail.stores.domain.manager.rtlog"
export="Y">
<PROPERTY propname="daemonClassName"
propvalue="oracle.retail.stores.domain.manager.rtlog.RTLogExportDaemonThread"/>
<PROPERTY propname="daemonName"
propvalue="RTLogExportDaemon"/>
<PROPERTY propname="sleepInterval"
propvalue="600"/>
<PROPERTY propname="exportDirectoryName"
propvalue="POSLog"/>
See Table 5-1, "Store Server Conduit File" in chapter 5 for more information.
The overall flow shown in is summarized in the following sequence:
Oracle Retail POS Suite creates and encrypts RTLog files.
If the RTLog is not successfully created due to unsupported mappings, the transaction identifier and exceptional condition is logged in detail on the Point-of-Service store server.
Transport middleware scans directory that Oracle Retail POS Suite writes the RTLog file to and reads in unprocessed RTLog files.
Transport middleware moves the RTLog file from the physical directory written to by Oracle Retail POS Suite to a physical directory on an enterprise server defined by Oracle Retail Sales Audit.
Oracle Retail Sales Audit consumes the RTLog file written to a pre-defined directory by the transport middleware, decrypts, and executes data cleansing operations to produce audited transaction data. See Oracle Retail POS Suite RTLog Files in this chapter.
Oracle Retail Sales Audit outputs audited RTLog-formatted transaction batch files and places the files into directories accessible by Oracle Retail Merchandising System.
A retailer may want to use DIMP with Release 14.1 of the POS Suite applications but with an earlier release of the Oracle Retail Merchandising Operations Management products. Cross version support enables this integration.
The installers for Oracle Retail Back Office and Oracle Retail Central Office have screens for cross version support. For more information, see the Oracle Retail Back Office Installation Guide and Oracle Retail Central Office Installation Guide.
For information on a cross version compatibility tool, see the following document available through My Oracle Support. Access My Oracle Support at the following URL:
https://support.oracle.com
Oracle Retail POS Suite Cross Version Compatibility Tool Overview (Doc ID: 1598607.1)
This document provides a technical overview of the Cross Version Compatibility Tool which aids retailers in integrating releases of Oracle Retail Merchandising System (RMS) and Oracle Retail Price Management (RPM) with Point-of-Service that were not integrated, tested, and released together.
