13 Integrations

This chapter describes the integration setup within EICS to Integrate with other systems.

For completed integration interfaces, see Oracle Retail Enterprise Inventory Cloud Service Administration Guide - Integration chapter.

• Pricing Integration with Retail Pricing Cloud Service

• Stock Count Export Integration with MFCS

• Sale Data Integration with POS and ReSA

• Xstore Integration - How does SIOCS Process Sales Transactions?

• Web Service: Integration with Manifest System

• Web Service: Integration with External System for Ticket Printing

• RIB Integration Guidance (From SIOCS Perspective)

• Other Integration Interfaces

• Standalone Deployment - Integration with on-premise RMS/RIB

• Standalone Deployment - Integration with GBUCS MFCS/RICS

Pricing Integration with Retail Pricing Cloud Service

Clearance Transaction Import

See Oracle® Retail Enterprise Inventory Cloud Service Administration Guide Batch Chapter: Clearance Transaction Import

Price Change Transaction Import

See Oracle® Retail Enterprise Inventory Cloud Service Administration Guide Batch Chapter: Price Change Transaction Import

Promotion Offer Import (N/A): Requires Field Enabled Integration

SIOCS does not use Oracle Retail Pricing Cloud Service Interface PromotionOffer_Tx. It requires field enabled integration. At this point, the pricing service does not post promotion price by item/date, so there is nothing for SIOCS to use. SIOCS does have a generic promotion interface for the retailer to integrate promotion price into.

Stock Count Export Integration with MFCS

Stock Count Export

When a Unit Amount stock count is authorized, a Unit and Amount Stock Counts Export file is generated.

See Oracle® Retail Enterprise Inventory Cloud Service Administration Guide Appendix: Unit and Amount Stock Counts Export.

Sale Data Integration with POS and ReSA

Retail Sale Audit Import Batch

See:

• Oracle® Retail Enterprise Inventory Cloud Service Administration Guide Batch chapter

• Oracle® Retail Enterprise Inventory Cloud Service Administration Guide Integration chapter

Xstore Integration - How does SIOCS Process Sales Transactions?

Configuration

SIOCS now does a-synchronous processing for sales transactions.

Processing

1. The basic form and structure of the POS transaction is validated. If this fails, the entire service call is rejected. *** please see validation checks for this step #1 below.

2. The transactions are broken up into items. Each item is then categorized as associated to order or not associated to order.

3. All records are written into POS_TRANSACTION table to be processed later.

4. MPS processing sub-queue is notified with a request number to process a group of transaction records.

5. MPS processes records in bulk groups by type for efficiency.

   • Items that succeed are processed.

   • Items that fail are written back to POS_TRANSACTION table with failed status and a record is written to POS_TRANSACTION_LOG to capture the failure

     *** please see error handling for this step #5 below.

Error Handling During Processing Step 1

If any error occurs in the first step, the entire web service call is failed and rejected.

The following errors can occur in Step 1.

• If sale upload is configured to GMT and a non-GMT date is sent.

• If more than one store is found on the input.

• If the single store found in the input is not an existing store.

• If the maximum number of (configured) total items is exceeded.

• If duplicate records are found in the input itself.

• If duplicate records are found in already existing data.

Error Handling During Step 5

If an unexpected or system error occurs, the entire request will fail, and all records associated to the request will not process.

If an expected or business error occurs, it is handled, and the specific item only is failed, and processing continues until the request is complete.

Failed items with business errors can be dealt with in SIOCS POS administration screen.

Note:

If a sales audit process is used, depending on the type of failure, the audit change process could send an audited file back to SIOCS, which means it may not be required to fix the error in SIOCS since it will be overlaid by the transaction coming from the sales audit application.

Web Service: Integration with Manifest System

See:

• Oracle® Retail Enterprise Inventory Cloud Service Administration Guide - Integrate with Manifest System

• Web Service URL:

  System Integrator provides the external Web Service URL. This URL is taken as input by the EICS installer to update system configuration entry in the database.

  The URL can also be updated via EICS System Configuration UI using the below configuration.

  SIOCS is not a package shipping management system. It calls an external shipping-manifest system that acts as a broker for multiple courier entities such as FedEX, UPS, DHL, national mail carriers and so on.

  Details of the shipping manifest web service are captured in the WSDL. Details of the data elements are provided in the XSD.

  • Download Shipping-Manifest-Service jar from the External Integration Artifacts Download Files section of MOS Doc ID 2614551.1.

  • Please look at all the definitions/wsdl in that JAR and write service as needed. This service will run on a server outside of Oracle network.

  • Please log a service request to allow-list this server URL.

  • Please use the Credentials Administration UI under Technical maintenance to update credential details. For details, please see Oracle® Retail Enterprise Inventory Cloud Service Administration Guide - Chapter 6.

• Web Service User alias: manifest-user

• Web Service: Integration with External System for Ticket Printing

Web Service: Integration with External System for Ticket Printing

See:

• Oracle® Retail Enterprise Inventory Cloud Service Administration Guide - Ticket Print

• Web Service URL:

  System Integrator provides the external Web Service URL. This URL is taken as input by the EICS installer to update system configuration entry in the database.

  SIOCS is not a printing system that manages printers & formats. Tickets are sent to an external web service endpoint; that is implemented by any system that needs to receive tickets. The external system is responsible for managing printing.

  Communication to the External printer can follow three paths:

  • Bluetooth or WiFi printing This method connects the mobile client (MAF) directly the printer. There is no need to leverage a print server. Depending on the implementation, SIOCS will send the ZPL and all relevant data directly to the connected printer.

  • MPS - Third party printing This method will leverage a web service to send ticket print requests to a network connected printer by leverage a print server maintained by the customer. There are two methods to connect to this external server depending on the “Maximum number of Tickets to use synchronous call” setting. If printing more tickets then configured SIOCS will send the print request to the MPS staging table.

  • Direct Webservice connect - Third party printing When printing less than the “maximum number of tickets to use synchronous” system option, SIOCS will send the ticket print request to a web service end point directly bypassing the MPS staging table. This is a faster method of communicating to the printer service, however this method should be reserved for small print quantities. When printing in bulk this method should be avoided.

  To process the staged tickets, the TicketPrint outbound MPS work type needs to be enabled through the MPS Work Type screen. Please refer to the Oracle Retail Enterprise Inventory Cloud Service Administration Guide for details on MPS Work Type screen.

  The external web service is called tps-TicketPrint and has one operation printTickets.

  Details of the ticket printing web service are captured in the WSDL. Details of the ticket data elements are provided in the XSD.

  • Download tps- TicketPrintService jar from the External Integration Artifacts Download Files section of MOS Doc ID 2614551.1.

  • Please look at all the definitions/wsdl in that JAR and write service as needed. This service will run on a server outside of Oracle network.

  • Please make sure outbound TicketPrint MPS work type has been enabled.

  • Please log a service request to allow-list this server URL.

  • Please use the Credentials Administration UI under Technical maintenance to update credential details. For details, please see Oracle® Retail Enterprise Inventory Cloud Service Administration Guide - Chapter 6.

• Web Service User alias: ticket-user

ZPL

• ZPL is a proprietary ticket formatting language used for printing to Zebra printers.

• ZPL is not entirely an ASCII format and is not readable without tools.

• If not using ZPL ticket printing on Zebra printers, then usage of ZPL is not recommended.

• If using ZPL with ZPL printers, SIOCS allows for the placement of tags within the ZPL design (managed by ZPL tools).

• SIOCS will then replace those tags with the correct data before sending the ticket information to the web service endpoint.

• ZPL files and formats are created and managed by tools and software outside of SIOCS. Files are uploaded into SIOCS.

Non-ZPL Printing

• Information captured in printer administration is sent with the ticket information, such as printer name and address.

• The custom development of the printing system (or middleware system designed to speak to a printing solution) must use the printer and ticket information to determine how to print.

• Ticket information can be used to determine format of ticket to print, but such tasks as matching the ticket type information to a template managed by the implementing system.

• Once a template in the middleware system is identified, the middleware system should use ticket information to populate the template and print the ticket. SIOCS does not manage printing templates.

• Printer information can be used to determine which printer it should be sent to.

• Printing templates are created and manages by tools and software outside of SIOCS as part of a custom or middleware product.

Figure 13-1 Ticket Printing

RIB Integration Guidance (From SIOCS Perspective)

Overview

The Oracle Retail Integration Bus (RIB) is a fully distributed integration infrastructure that implements messaging using Asynchronous JMS Publish/Subscribe Fire-and-Forget model.

The concept of message-bus is that one product broadcasts information and each product or cloud service only subscribes to those message families/payloads that they are interested in. Everything else is ignored.

To process all messages intended for ordering systems, pricing systems, or any other external systems would require massive processing of mapping, then writing to the database, and then reading messages that are not intended for processing in our system to discard them.

To avoid all the processing and overhead, messages not intended for SIOCS are simply dropped at the point of receiving them from the RIB.

Unsupported Messages and Payloads

When an entire family or message type is not used or desired in SIOCS, then it is not subscribing to and does not arrive at SIOCS.

The message type and payload have no injector that places the RIB payload into the MPS staged message processing workflow in SIOCS.

Unsupported Data within Messages and Payloads

In the case of some message families or types, a brief look at the internal information of the message may also determine, it is not meant for SIOCS.

1. SIOCS does not process non-stockholding stores (stores with no inventory). So, if a payload arrives for a message family and type we support, but the payload contains an internal attribute, usually labeled "stockholding_ind" that is set to "N", the payload is dropped as it is not intended for the SIOCS system.

2. SIOCS does not process virtual stores so limited itself by store type. If the payload contains a store type attribute, then SIOCS only processes COMPANY ("C") stores and FRANCHISE ("F") stores.

3. When dealing with quantities, a quantity of 0 primarily means a cancellation or removal of that item or detail from a transaction, and so it is deleted. There may be exception to this in certain circumstances.

Errors

Errors that occur within the RIB through injection in MPS are logged and managed within the RIB.

Errors that occur within MPS staged messages within SIOCS are logged and can be seen and managed with MPS management workflow.

Messages that are successfully processed, including successfully being ignored as not relevant to the store, do not log any information.

Modify/Delete

In the case of transaction data, in some cases if the transaction is actively being processed by a user or business functionality in the store, it may have already passed a state where it can be modified or canceled.

Message Family/Type

The following table contains a list of message families and types that SIOCS subscribes to (incoming) or broadcasts (publishes out) to other systems.

It indicates the family name, message type, payloads used within the family, whether SIOCS publishes or subscribes to it, and whether it is part of the initial data seeding.

Message type suffixes indicates intent of the payload: Cre means create information, Mod means modify information, and Del means cancel or delete information.

Table 13-1 Message Family/Type

Message Family	Message Type	Payload	Publish/ Subscribe	Seeded	SIOCS Data
ASNIn	ASNInCre ASNInMod	ASNInDesc	Subscribe	No	Store Delivery
ASNOut	ASNOutCre	ASNOutDesc	Publish	No	Store Shipment
ClrPrcChg	ClrPrcChgCre ClrPrcChgMod ClrPrcChgDel	ClrPrcChgDesc ClrPrcChgRef ClrPrcChgDtlRef	Subscribe	No	Clearance Price Change
CoInvAvail	COInvAvailMod	COInvAvailDesc	Publish	No	Customer Order Store Inventory Shift Notification
Diffs	DiffCre DiffDel DiffMod	DiffDesc DiffRef	Subscribe	Yes	Differentiators
DSDReceipt	DSDReceiptCre DSDReceiptMod	DSDReceiptDesc	Publish	No	Non-PO DSD Receipt
FulfilOrd	FulfilOrdStDlvCre FulfilOrdReqDel FulfilOrdApprDel	FulfilOrdDesc	Subscribe	No	Fulfillment Orders
FulfilOrdCfm	FulfilOrdCfmCre	FulfilOrdCfmDesc	Publish	No	Fulfillment Order Confirm
FulfilOrdCfmCnc	FulfilOrdCfmCncCre	FulfilOrdRef	Publish	No	Fulfillment Order Cancel
InvAdjust	InvAdjustCre	InvAdjustDesc	Publish, Subscribe	No	Stock Movement Notification
InvReq	InvReqCre	InvReqDesc	Publish	No	Store Order/Item Request
ItemLoc	ItemLocCre ItemLocDel ItemLocMod ItemLocReplMod	ItemLocDesc	Subscribe	Yes	Item Location Item Replenishment
Items	ItemBOMCre ItemBOMDel ItemBOMMod ItemCre ItemDel ItemHdrMod ItemImageCre ItemImageMod ItemImageDel ItemUPCCre ItemUPCDel ItemUPCMod	ItemBOMDesc ItemDesc ItemHdrDesc ISCDimDesc ItemImageDesc ItemTcktDesc ItemUPCDesc	Subscribe	Yes	Item Item Details Item UPC Item Image
Items	RelItemHeadCre RelItemHeadMod RelItemHeadDel RelItemDetCre RelItemDetDel RelItemDetMod	RelatedItemDesc	Subscribe	Yes	Related Items
Items	ItemSupCre ItemSupDel ItemSupMod ItemSupCtyCre ItemSupCtyDel ItemSupCtyMod ISCDimCre ISCDimMod ISCDimDel ISCMfrCre ISCMfrDel ISCMfrMod	ItemSupCtyDesc ItemSupCtyMfrDesc ItemSupDesc	Subscribe	Yes	Supplier Items Supplier Manufacturer Supplier Country
Items	ItemUDALOVCre ItemUDALOVMod ItemUDALOVDel ItemUDAFFCre ItemUDAFFMod ItemUDAFFDel ItemUDADateCre ItemUDADateMod ItemUDADateDel	ItemUDADateDesc ItemUDAFFDesc ItemUDALOVDesc	Subscribe	Yes	Item User Defined Attributes
MerchHier	ClassCre ClassMod ClassDel DeptCre DeptMod DeptDel SubclassCre SubclassMod SubclassDel	MrchHrClsDesc MrchHrDeptDesc MrchHrSclsDesc	Subscribe	Yes	Department Class Subclass
Order	POCre PODel PODtlCre PODtlDel PODtlMod POHdrMod	PODesc PORef	Subscribe	No	Purchase Order
Partner	PartnerCre PartnerDel PartnerMod PartnerDtlCre PartnerDtlDel PartnerDtlMod	PartnerDesc PartnerOUDesc PartnerRef	Subscribe	Yes	Finishers
PrmPrcChg	MultiBuyPromoCre MultiBuyPromoMod MultiBuyPromoDel PrmCnlItemLocCre	PromotionDesc	Subscribe	No	Promotions
RcvUnitAdj	RcvUnitAdjCre RcvUnitAdjMod	RcvUnitAdjDesc	Subscribe	No	Adjusts Supplier Deliveries
Receiving	ReceiptCre ReceiptOrdCre	ReceiptDesc	Publish	No	Transfer Receipt, Purchase Order Receipt, Receipt with Customer Order
RegPrcChg	RegPrcChgCre RegPrcChgMod RegPrcChgDel	RegPrcChgDesc RegPrcChgDtl	Subscribe	No	Regular Price Change
RTV	RTVCre	RTVDesc	Publish, Subscribe	No	Warehouse Return
RTVReq	RTVReqCre RTVReqMod RTVReqDel RTVReqDtlCre RTVReqDtlDel RTVReqDtlMod	RTVReqDesc RTVReqRef	Subscribe	No	Supplier Return
SeedData	DiffTypeCre DiffTypeDel DiffTypeMod	DiffTypeDesc DiffTypeRef	Subscribe	Yes	Differentiator Types
ShipInfo	ShipInfoCre	ShipInfoDesc	Publish	No	Pre-Shipment Notification
SOStatus	SOStatusCre	SOStatusDesc	Publish, Subscribe	No	Transfers Shipments
StkCountSch	StkCountSchCre StkCountSchMod StkCountSchDel StkCountSchDtlDel	StkCountSchDesc	Publish	No	Stock Count Schedule
StockOrder	SOCre SODtlCre SODtlDel SODtlMod SOHdrDel SOHdrMod	SODesc SORef	Subscribe	No	Transfer Allocation
Stores	StoreCre StoreDel StoreMod StoreDtlCre StoreDtlDel StoreDtlMod	StoreDesc StoreRef	Subscribe	Yes	Store
UDAs	UDAHdrCre UDAHdrMod UDAHdrDel UDAValCre UDAValMod UDAValDel	UDADesc UDARef UDAValDesc UDAValRef	Subscribe	No	User Defined Attributes
Vendor	VendorAddrCre VendorAddrDel VendorAddrMod VendorCre VendorDel VendorHdrMod VendorOUCre VendorOUDel	VendorAddrDesc VendorAddrRef VendorDesc VendorRef	Subscribe	Yes	Suppliers
WH	WHCre WHDel WHMod	WHDesc WHRef	Subscribe	Yes	Warehouse

Other Integration Interfaces

See Oracle® Retail Enterprise Inventory Cloud Service Administration Guide Integration chapter.

Standalone Deployment - Integration with on-premise RMS/RIB

SIOCS V22 has enabled standalone deployment (that is, not shared pluggable database with MFCS) option. In order to integrate with on-premise Retail merchandising system, field enablement would be needed.

As noted in the Oracle SIOCS Implementation Overview chapter, File Transfer Service (FTS) would play a key role in enabling this integration.

Depending on the version of Retail Merchandising System (RMS), RIB payloads may differ as well. Implementers will have to do analysis. If your RMS version is V19 or V16 then payloads would be much more compatible in terms of required attributes; than dealing with pre-V16 RMS.

Please note that RIB (retail integration bus) would always deploy where Merchandising gets deployed; hence RIB-on-premise would interact with SIOCS.

At high level, field enablement would be needed for:

• Foundation Data seeding and pricing

  For file layout and more detail, please see the Standalone Data Seeding section in the Oracle Retail Enterprise Inventory Cloud Service Administration Guide.

• File movement between SIOCS and Merchandising

  • ReSA import into SIOCS

  • Stk count export from SIOCS to Merchandising

• 3rd party file imports

  For more information, please see the FTS Enabled Third Party File Import Batches section within the File Transfer Services chapter in the Oracle Retail Enterprise Inventory Cloud Service Administration Guide.

• In order to call RIB instance located on-premises from SIOCS V22, RIB endpoint needs to be allow listed. Create a service request on My Oracle Support to allow list the on-premises server url.

  • Once allow listed, SIOCS to RMS communication via RIB can commence through standard RIB- SOAP services.

  • Similarly on-premise RMS would use RIB-SOAP-injector service to communicate with SIOCS.

Standalone Deployment - Integration with GBUCS MFCS/RICS

SIOCS V22 has enabled standalone deployment (that is, not shared pluggable database with MFCS) integration option with MFCS/RICS v 19.x deployed in GBUCS.

Please note that RICS (retail integration cloud service) would always deploy where Merchandising gets deployed.

Biggest difference between GBUCS cloud and NextGen Cloud is use of sFTP v/s Object storage (FTS - file transfer service) for file movement.

Before starting, please verify with Oracle AMS team about this mixed mode deployment.

In this deployment, following integration takes place.

• ReSA files from MFCS/GBUCS to SIOCS

  • MFCS invokes FTS end points to push files from sFTP

• Pricing - regular and clearance files get pushed from pricing cloud service (part of MFCS) into SIOCS's object storage (FTS)

  • Pricing import files are pulled & processed from object storage into application item price tables.

  • On completion, the processed files are moved to SIOCS FTS internal archive file location and purged after configured days.

  • On failures, the failed records are written to reject files, and the reject files are sent to object storage rejects location. The errors can be viewed via SIOCS job admin UI or can be downloaded via table in job admin UI.

  • To re-run the corrected data files, user can place the corrected data files into SIOCS FTS/object storage import location, and the import batch will process the data files.

• Stock count file gets pushed from SIOCS's object storage to MFCS's sFTP

• MFCS will continue to send inventory transactions via RIB messages to SIOCS

  • ** SIOCS end points are publicly exposed

• SIOCS will continue to send inventory transaction RIB messages to MFCS

  • ** url will be whitelisted & configured on SIOCS to allow this