| Oracle® Retail Merchandising Foundation Cloud Service Operations Guide Volume 2 - Message Publication and Subscription Designs Release 16.0.028 E97817-01 |
|
 Previous |
 Next |
| Oracle® Retail Merchandising Foundation Cloud Service Operations Guide Volume 2 - Message Publication and Subscription Designs Release 16.0.028 E97817-01 |
|
Previous |
Next |
This chapter gives an overview about the SOAP Web service provider implementation API designs used in the RMS environment and various functional attributes used in the APIs.
|
Note: The following service provider implementation API designs are intended only to give a high level overview of the APIs available.The implementation of these services, along with the associated Web Service Definition Language (WSDL), may be used to get a full understanding of the data requirements, validation rules, persistence rules, and return values associated with the service. |
This section describes the supplier service.
RMS subscribes supplier information from external financial applications via this Web service. The Supplier Service Provider is used by external financial systems to send RMS the supplier information that includes supplier addresses, CFAS data and the operating unit. The header record contains information about the supplier as a whole. The address records identify the addresses associated with the supplier and the operating unit records specify the operating units associated with the supplier.
This public package is called by the supplier Web service to send supplier information to RMS.
Filename: rmsaiasub_suppwebss/b.pls
SupplierServiceProviderImpl.createSupplierDesc (I_serviceoperationcontext IN "RIB_ServiceOpContext_REC", I_businessobject IN "RIB_SupplierDesc_REC", O_serviceoperationstatus OUT "RIB_ServiceOpStatus_REC", O_businessobject OUT "RIB_SupplierRef_REC")
This procedure populates the first record of "RIB_SupplierColDesc_REC" and passes the record to the function RMSAIASUB_SUPPLIER.CONSUME() with a message type of 'suppadd'. The procedure RMSAIA_LIB.BUILD_SERVICE_OP_STATUS() is used to return status to the calling Web service. If there is any error then the O_error_message from consume will be assigned to the RIB_OBJECT O_serviceOperationStatus as per the signature of the new RIB_OBJECT.
SupplierServiceProviderImpl.updateSupplierDesc (I_serviceoperationcontext IN "RIB_ServiceOpContext_REC", I_businessobject IN "RIB_SupplierDesc_REC", O_serviceoperationstatus OUT "RIB_ServiceOpStatus_REC", O_businessobject OUT "RIB_SupplierDesc_REC")
This procedure populates the first record of "RIB_SupplierColDesc_REC" and passes the record to the function RMSAIASUB_SUPPLIER.CONSUME() with a message type of 'suppmod'. The procedure RMSAIA_LIB.BUILD_SERVICE_OP_STATUS() is used to return status to the calling Web service. If there is any error then the O_error_message from consume will be assigned to the RIB_OBJECT O_serviceOperationStatus as per the signature of the new RIB_OBJECT.
The following procedures are part of the package, but are not supported by RMS. When called by the Web service, these procedures will return without further processing with an error message "This webservice is not supported now". These procedures are:
"SupplierServiceProviderImpl.createSupSiteUsingSupplierDesc()
"SupplierServiceProviderImpl.updateSupSiteUsingSupplierDesc()
"updateSupSiteAddrUsingSupplier()
"updateSupSiteOrgUnitUsingSuppl()
"updateSupSiteUsingSupplierDesc()
"createSupSiteAddrUsingSupplier()
"createSupSiteUsingSupplierDesc()
"findSupplierDesc()
"deleteSupplierDesc()
"findSupplierColDesc()
"deleteSupplierColDesc()
SupplierServiceProviderImpl.updateSupplierColDesc (I_serviceOperationContext IN "RIB_ServiceOpContext_REC", I_businessObject IN "RIB_SupplierColDesc_REC", O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC", O_businessObject OUT "RIB_SupplierColDesc_REC")
This procedure passes the record to the function RMSAIASUB_SUPPLIER.CONSUME() with message type as "suppmod". The procedure RMSAIA_LIB.BUILD_SERVICE_OP_STATUS() is used to return status to the calling Web service.
SupplierServiceProviderImpl.createSupplierColDesc (I_serviceoperationcontext IN "RIB_ServiceOpContext_REC", I_businessobject IN "RIB_SupplierColDesc_REC", O_serviceoperationstatus OUT "RIB_ServiceOpStatus_REC", O_businessobject OUT "RIB_SupplierColRef_REC")
This procedure passes the record to the function RMSAIASUB_SUPPLIER.CONSUME() with message type as "suppadd". The procedure RMSAIA_LIB.BUILD_SERVICE_OP_STATUS() is used to return status to the calling Web service.
This is the main consume function:
RMSAIASUB_SUPPLIER.CONSUME
(O_status_code IN OUT VARCHAR2,
O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE,
O_outputobject IN OUT "RIB_SupplierColRef_REC",
I_inputobject IN "RIB_SupplierColDesc_REC",
I_inputobject_type IN VARCHAR2)
This procedure is called by the package SupplierServiceProviderImpl to consume supplier information coming from the Financial System via the Web service. It then validates the data and persists it to the RMS Supplier tables. It does most of the validation through the RMSAIASUB_SUPPLIER_VALIDATE.PROCESS_SUPPLIER_RECORD() function, which utilizes the internal functions VALIDATE_RECORD() and POPULATE_RECORD. After the validation checks the data, the RMSAIASUB_SUPPLIER_SQL.PERSIST() is called to update the RMS supplier maintenance tables.
The function RMSAIASUB_SUPPLIER_CFA.CONSUME is called to subscribe the CFAS information.
RMSSUB_SUPPLIER_VAL.PROCESS_SUPPLIER_RECORD (O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_supplier_object IN OUT SUPP_REC, O_ref_outputobject IN OUT "RIB_SupplierColRef_REC", I_inputobject IN "RIB_SupplierColDesc_REC", I_inputobject_type IN VARCHAR2)
This function is the main validation function for the supplier Web service interface. It calls various internal functions to verify NULLs, validate codes in the CODE_DETAIL table, or confirm values have the necessary foreign keys in the RMS system. If the validation processes do not fail, the next step is to populate the local record groups to be used later for populating RMS tables.
RMSAIASUB_SUPPLIER_SQL.PERSIST (O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, I_supplier_record IN OUT SUPP_REC)
This function is called from RMSAIASUB_SUPPLIER.CONSUME() to insert into the RMS tables. The following internal functions are utilized:
INSERT_SUPPLIER
This function will insert to the SUPS table is it does not exist yet, and will update the records if it already exists in RMS.
INSERT_SUPPLIER_SITES
This function will insert to the SUPS table is it does not exist yet, and will update the records if it already exists in RMS.
INSERT_ADDRESS
This function will insert to the ADDR table is it does not exist yet, and will update the records if it already exists in RMS.
INSERT_ORG_UNIT
This function will insert to the PARTNER_ORG_UNIT table is it does not exist yet, and will update the records if it already exists in RMS.
RMSAIASUB_SUPPLIER_CFA.CONSUME
(O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE,
I_inputobject IN "RIB_SupplierColDesc_REC",
I_supp_rec IN SUPP_REC)
This function is called from RMSAIASUB_SUPPLIER.CONSUME() to insert the CFAS data into CFAS tables. It has the following internal functions:
BUILD_SUPS_CFA_PK
This function will build the key value pairs for supplier.
BUILD_ADDR_CFA_PK
This function will build the key value pairs for supplier address.
CONSUME_ADDR_CFAS
This function will insert CFAS attributes of supplier address into CFAS table.
The Web service initially calls the package SupplierServiceProviderImpl that serves as a wrapper for the main consume function RMSAIASUB_SUPPLIER.CONSUME(). The consume function utilizes the packages RMSSUB_SUPPLIER_VAL and RMSAIASUB_SUPPLIER_SQL to process the supplier data consumption.
| TABLE | SELECT | INSERT | UPDATE | DELETE |
|---|---|---|---|---|
| SUPS | Yes | Yes | Yes | No |
| ADDR | Yes | Yes | Yes | No |
| SYSTEM_OPTIONS | Yes | No | No | No |
| UNIT_OPTIONS | Yes | No | No | No |
| CODE_DETAIL | Yes | No | No | No |
| PARTNER_ORG_UNIT | Yes | Yes | Yes | No |
| ORG_UNIT | Yes | No | No | No |
| CFA_EXT_ENTITY | Yes | No | No | No |
| CFA_ATTRIB_GROUP_SET | Yes | No | No | No |
| SUPS_CFA_EXT | No | Yes | No | No |
| ADDR_CFA_EXT | No | Yes | No | No |
This section describes the pay term service.
The Pay Term Service Provider is used by external financial systems to send RMS new and updated payment term information. Header and detail level payment term information is written to the TERMS_HEAD and TERMS_DETAIL tables.
This document describes the Pay Term Web service integration between RMS and an external financial application. In this integration context, RMS acts as the service provider that exposes a Web service to be invoked by an external financial application.
The process flow diagram for Pay Term Service API.
Filename: rmsaiasub_ptrmwebss/b.pls
Package name: PayTermServiceProviderImpl
createPayTermDesc
(I_serviceOperationContext IN "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_PayTermDesc_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_PayTermRef_REC")
This procedure corresponds to the 'create' operation of the Pay Term Web service. It calls RMSAIASUB_PAYTERM.CONSUME with a message type of RMSAIASUB_PAYTERM.HDR_ADD to create payment terms in RMS. It returns RMS's pay term ID through output O_businessObject and success or failure status through O_serviceOperationStatus.
createDetailPayTermDesc
(I_serviceOperationContext IN "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_PayTermDesc_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_PayTermRef_REC")
This procedure corresponds to the 'createDetail' operation of the Pay Term Web service. It calls RMSAIASUB_PAYTERM.CONSUME with a message type of RMSAIASUB_PAYTERM.DTL_ADD to create payment term details in RMS. It returns RMS's pay term ID through output O_businessObject and success or failure status through O_serviceOperationStatus.
updatePayTermDesc
(I_serviceOperationContext IN "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_PayTermDesc_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_PayTermDesc_REC")
This procedure corresponds to the 'update' operation of the Pay Term Web service. It calls RMSAIASUB_PAYTERM.CONSUME with a message type of RMSAIASUB_PAYTERM.DTL_UPD to update payment terms in RMS. It returns a "RIB_PayTermDesc_REC' object through output O_businessObject and success or failure status through O_serviceOperationStatus.
updateHeaderPayTermDesc
(I_serviceOperationContext IN "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_PayTermDesc_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_PayTermDesc_REC")
This procedure corresponds to the 'updateHeader' operation of the Pay Term Web service. It calls RMSAIASUB_PAYTERM.CONSUME with a message type of RMSAIASUB_PAYTERM.HDR_UPD to update header level payment term information in RMS. It returns a "RIB_PayTermDesc_REC' object through output O_businessObject and success or failure status through O_serviceOperationStatus.
updateDetailPayTermDesc
(I_serviceOperationContext IN "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_PayTermDesc_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_PayTermDesc_REC")
This procedure corresponds to the 'updateDetail' operation of the Pay Term Web service. It calls RMSAIASUB_PAYTERM.CONSUME with a message type of RMSAIASUB_PAYTERM.DTL_UPD to update detail level payment term information in RMS. It returns a "RIB_PayTermDesc_REC' object through output O_businessObject and success or failure status through O_serviceOperationStatus.
Package name: RMSAIASUB_PAYTERM
CONSUME(O_status_code OUT VARCHAR2,
O_error_message OUT VARCHAR2,
O_rib_paytermref_rec OUT "RIB_PayTermRef_REC",
I_message IN "RIB_PayTermDesc_REC",
I_message_type IN VARCHAR2)
This procedure validates the message content in I_message with respect to the message type (I_message_type) and persists payment terms information in RMS's TERMS_HEAD and TERMS_DETAIL tables. It returns RMS's term ID through output O_rib_paytermref_rec.
Package name: RMSAIASUB_PAYTERM_VALIDATE
FUNCTION CHECK_MESSAGE(O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE,
O_paytermref_rec IN OUT "RIB_PayTermRef_REC",
O_payterm_rec IN OUT TERMS_SQL.PAYTERM_REC,
I_message IN "RIB_PayTermDesc_REC",
I_message_type IN VARCHAR2)
RETURN BOOLEAN;
This function performs validation on the message content in I_message with respect to the message type (I_message_type). It returns RMS's term ID through output O_rib_paytermref_rec.
Package name: RMSAIASUB_PAYTERM_SQL
FUNCTION PERSIST(O_error_message OUT RTK_ERRORS.RTK_TEXT%TYPE,
I_message IN TERMS_SQL.PAYTERM_REC,
I_message_type IN VARCHAR2)
RETURN BOOLEAN;
This function calls TERMS_SQL.MERGE_HEADER and TERMS_SQL.MERGE_DETAIL functions to persist payment terms information to RMS's TERMS_HEAD and TERMS_DETAIL tables.
Package name: TERMS_SQL
FUNCTION MERGE_HEADER(O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE,
I_paytermrec IN PAYTERM_REC)
RETURN BOOLEAN;
This function persists payment terms header level information to RMS's TERMS_HEAD table.
FUNCTION MERGE_DETAIL(O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE,
I_paytermrec IN PAYTERM_REC)
RETURN BOOLEAN;
This function persists payment terms detail level information to RMS's TERMS_DETAIL table.
| Message Types | Message Type Description | XML Schema Definition (XSD) |
|---|---|---|
| paytermcre | create payment terms | PayTermDesc.xsd, PayTermRef.xsd |
| paytermmod | update payment terms header | PayTermDesc.xsd, PayTermRef.xsd |
| paytermdtlcre | create payment terms detail | PayTermDesc.xsd, PayTermRef.xsd |
| paytermdtlmod | Update payment terms detail | PayTermDesc.xsd, PayTermRef.xsd |
This section describes the customer order fulfillment subscription API.
RMS provides an interface to process Customer Order Fulfillment requests from an external order management system (OMS). If the system option OMS_IND = 'Y', then RMS expects to receive customer orders via this API. If the system option PERSIST_CUSTOMER_DATA_IND = ’N', personal information will not be stored in the customer order table in RMS.
RMS supports two integration methods for processing Customer Order Fulfillment messages from OMS - either through RIB or Web service. At implementation time, clients should decide on either one or the other integration method, but not both. The same core logic is used to validate and persist customer orders to RMS tables.
In a RIB implementation, RMS subscribes to Customer Order Fulfillment messages. When a customer order is created, or partially or fully cancelled, the customer order information is sent from the Order Management System (OMS) to the RIB. RMS subscribes to the customer order information as published from the RIB and places the information onto RMS tables.
In a Web service implementation, RMS exposes a FulfillOrder Web service to create or cancel a customer order in RMS. OMS will invoke the service with customer order details to place the information on RMS tables.
The Customer Order Fulfillment message staged in the RMS tables will go through a process of validation. Records that pass validation will create new customer order records. If any validation error occurs, transaction will be rolled back and no customer orders will be created.
There are two scenarios where a customer order fulfillment request cannot be created in RMS:
Due to data validation errors (for example, invalid item).
Due to 'No Inventory' - There is not enough inventory available at the source location or item is not ranged or inactive at the source location, or item is not supplied by the supplier (in a PO scenario).
Accepts a collection of fulfillment orders as input. If one order fails, the entire service call fails and no order will be created in RMS.
RMS returns Failure status as part of the response object in the Web service call if customer orders are not created due to validation errors.
RMS returns Success status and a confirmation message of type 'X' as part of the response object if customer orders are not created due to 'No Inventory' or a confirmation message of type 'P' if customer orders are partially created due to insufficient inventory.
Accepts a single fulfillment order as input to allow RIB's sequencing mechanism to work as designed.
RMS returns Failure to the RIB and the message will land in the RIB hospital if a customer order is not created due to validation errors. No confirmation message will be sent.
RMS returns Success. In a separate transaction, a confirmation message of type 'X' will be sent to the RIB if a customer order is not created due to 'No Inventory', or a confirmation message of type 'P' will be sent to the RIB if a customer order is partially created due to insufficient inventory. Based on the confirmation message, OMS will take action to source the order from a different location. See Customer Order Fulfillment Confirmation Publication API.
The Customer Order Fulfillment messages contain information such as delivery type, source type and destination type. Based on these, the system should proceed to create a Purchase Order, Transfer or Inventory Reservation. The table below shows the customer order scenarios for the combination of delivery type, source type and destination type.
| Scenario # | Source Location | Fulfillment Location | Delivery Type | Transaction created |
|---|---|---|---|---|
| 1 | Warehouse | Store | Pickup in Store | Virtual WH to Physical Store Transfer + Reservation.
FulfilOrdDesc will contain: 1st leg: source_loc_type = 'WH', fulfill_loc_type = 'S' 2nd leg: source_loc_type = NULL, fulfill_loc_type = 'S'. |
| 2 | Warehouse | Store | Ship to Customer | Virtual WH to Physical Store Transfer + Reservation.
FulfilOrdDesc will contain: 1st leg: source_loc_type = 'WH', fulfill_loc_type = 'S' 2nd leg: source_loc_type = NULL, fulfill_loc_type = 'S'. |
| 3 | Store A | Store B | Pickup in Store | Physical Store to Physical Store Transfer + Reservation.
FulfilOrdDesc will contain: 1st leg: source_loc_type = 'ST', fulfill_loc_type = 'S' 2nd leg: source_loc_type = NULL, fulfill_loc_type = 'S'. |
| 4 | Store A | Store B | Ship to Customer | Physical Store to Physical Store Transfer + Reservation.
FulfilOrdDesc will contain: 1st leg: source_loc_type = 'ST', fulfill_loc_type = 'S' 2nd leg: source_loc_type = NULL, fulfill_loc_type = 'S'. |
| 5 | NULL | Store | Pickup in Store | Reservation.
FulfilOrdDesc will contain: Single-leg: source_loc_type = NULL, fulfill_loc_type = 'S'. |
| 6 | NULL | Store | Ship to Customer | Reservation.
FulfilOrdDesc will contain: Single-leg: source_loc_type = NULL, fulfill_loc_type = 'S'. |
| 7 | NULL | Warehouse | Ship to Customer | Virtual WH to Virtual Store Transfer.
FulfilOrdDesc will contain: Single-leg: source_loc_type = 'WH', fulfill_loc_type = 'V'. |
| 8 | Vendor | Store | Pickup in Store | Purchase Order to Physical Store + Reservation.
FulfilOrdDesc will contain: 1st leg: source_loc_type = 'SU', fulfill_loc_type = 'S' 2nd leg: source_loc_type = NULL, fulfill_loc_type = 'S'. |
| 9 | Vendor | Store | Ship to Customer | Purchase Order to Physical Store+ Reservation.
FulfilOrdDesc will contain: 1st leg: source_loc_type = 'SU', fulfill_loc_type = 'S' 2nd leg: source_loc_type = NULL, fulfill_loc_type = 'S'. |
| 10 | NULL | Vendor | Ship to Customer | Purchase Order to Virtual Store
FulfilOrdDesc will contain: Single-leg: source_loc_type = 'SU', fulfill_loc_type = 'V'. |
The customer order subscription API supports create and cancel operations using the following message types belonging to the 'fulfilord' message family:
fulfilordapprdel - used by RMS to cancel customer orders.
fulfilordreqdel - used by SIM to request a customer order cancellation. This message type is used only by SIM and is ignored by RMS.
fulfilordpocre - used to create purchase orders as a result of customer order fulfillment requests.
fulfilordtsfcre - used to create transfers as a result of customer order fulfillment requests.
fulfilordstdlvcre - used to perform inventory reservation as a result of customer order fulfillment requests.
In a RIB implementation, once fulfillment create messages are processed in RMS, RMS will publish to the RIB a customer order fulfillment confirmation message with a message type of 'fulfilordcfmcre' via the customer order fulfillment confirmation publishing API, rmsmfm_ordcust. Confirmation messages will only be sent for customer order fulfillment creates requests that result in creating purchase orders and transfers in RMS. It will not be sent for cancel requests, or for customer order fulfillment requests that result in inventory reservation.
If a customer order is partially fulfilled, a confirmation message with status 'P' will be sent with details of fulfilled order quantity.
If a customer order is not fulfilled at all due to unavailable inventory, a confirmation message with status 'X' will be sent without any details.
In a Web service implementation, confirmation messages will be sent in a collection as part of the response object. In a RIB implementation, separate confirmation messages will be published from RMS in independent transactions.
This section describes the package impact.
Filename: stgsvc_fulfilords/b.pls
This package provides public interfaces (pop_create_tables and pop_cancel_tables) to stage customer order fulfillment create and cancel requests in the collection to interface tables. It also provides a public interface (cleanup_tables) to clear out data in the interface staging tables after processing.
Filename: coresvc_fulfilordvals/b.pls
This package contains logic that performs generic validation of customer order fulfillment create and cancel requests in the following interface staging tables:
SVC_FULFILORD
SVC_FULFILORDDTL
SVC_FULFILORDCUST
SVC_FULFILORDREF
SVC_FULFILORDDTLREF
SVC_BRFULFILORDCUST
Filename: rmssub_fulfilords/b.pls
RMS will subscribe to the customer order fulfillment create or cancel message from the RIB. The RIB message will be parsed and staged into staging tables for initial validation via stgsvc_fulfilord.pop_tables. The coresvc_fulfilordval package will be called to perform generic validation. If no error is encountered during initial validation, transfer, PO, inventory reservation specific validation functions will be invoked to perform further validation and to create customer order transfers, purchase orders, or reserve inventory in RMS. The staging table will be purged at the end of the processing.
The diagram RIB JMS Deployment for Customer Order Fulfillment Requests illustrates this process:
Filename: FulfillOrderServiceProviderImplSpec.pls FulfillOrderServiceProviderImplBody.pls
For a Web service deployment, a new Web service 'FulfillOrder' with two supported operations of 'create' and 'cancel' is available for OMS to send customer order fulfillment create and cancel requests to RMS. The Web services will invoke public interfaces for the Customer Order Fulfillment Create Request (FulfillOrderServiceProviderImp.createFulfilOrdColDesc) and the Customer Order Fulfillment Cancel Request (FulfillOrderServiceProviderImp.cancelFulfilOrdColRef).
These public interfaces calls create and cancel procedures in svcprov_fulfilord to do major processing logic. Similar to a RIB JMS deployment, the messages will be staged, validated, and persisted to RMS using the same core functions. At the end of the processing, the staging tables are purged and a confirmation status is returned.
The diagram Web Service Deployment for Customer Order Fulfillment Requests illustrates this process.
Here are the filenames that correspond with each message type. Please consult the RIB documentation for each message type in order to get a detailed picture of the composition of each message.
| Message Types | Message Type Description | XML Schema Definition (XSD) |
|---|---|---|
| Fulfilordapprdel | Fulfilment Cancel Message | FulfilOrdRef.xsd |
| Fulfilordreqdel | Fulfilment Cancel Request Message | FulfilOrdRef.xsd |
| Fulfilordpocre | Fulfilment PO Create Message | FulfilOrdDesc.xsd |
| Fulfilordtsfcre | Fulfilment Transfer Create Message | FulfilOrdDesc.xsd |
| Fulfilordstdlvcre | Fulfilment Store Delivery Create Message | FulfilOrdDesc.xsd |
Customer order fulfillment request cannot be created in RMS for the following scenarios:
Customer orders are not created due to any validation error.
Customer orders are created in 'X' status due to 'no inventory' (for example, not enough available at the source location, or item not ranged to or active at the source location, or in a PO scenario, item not supplied by the supplier).
Non-stockholding franchise stores cannot part of a customer order, either as a sourcing location or as a fulfillment location.
Only approved, inventoried and sellable items will be published to OMS. Therefore, item types like catch weight, concession, consignment, and transformable sellable items will NOT be published to OMS, and will NOT be supported by this interface. To sell items that can vary by weight, like bananas, through online channels, setup should be done as a regular (non-catch weight) item with a unit cost and standard UOM defined in items of eaches.
It is assumed that customer orders will be captured in the selling UOM in OMS, but that all transactions will be communicated to RMS in standard UOM.
| TABLE | SELECT | INSERT | UPDATE | DELETE |
|---|---|---|---|---|
| SVC_FULFILORDREF | Yes | Yes | Yes | Yes |
| SVC_FULFILORDREFDTL | Yes | Yes | Yes | Yes |
| SVC_FULFILORD | Yes | Yes | Yes | Yes |
| SVC_FULFILORDCUST | Yes | Yes | Yes | Yes |
| SVC_FULFILORDDTL | Yes | Yes | Yes | Yes |
| SVC_BRFULFILORDCUST | Yes | Yes | Yes | Yes |
| TSFHEAD | Yes | Yes | Yes | No |
| TSFDETAIL | Yes | Yes | Yes | No |
| ORDCUST | Yes | Yes | No | No |
| ORDCUST_DETAIL | Yes | Yes | Yes | No |
| ORDHEAD | Yes | Yes | Yes | Yes |
| ORDLOC | Yes | Yes | Yes | No |
| ORDSKU | Yes | Yes | No | No |
| ORDSKU_HTS | No | Yes | No | No |
| ORDSKU_HTS_ASSESS | No | Yes | No | No |
| ORDLOC_EXP | No | Yes | Yes | No |
| TSFHEAD | Yes | Yes | Yes | No |
| TSFDETAIL | Yes | Yes | Yes | No |
| TSFHEAD_L10N_EXT | No | Yes | Yes | No |
| ORDCUST_L10N_EXT | No | Yes | Yes | No |
| ORDCUST_PUB_TEMP | No | Yes | No | No |
| ITEM_MASTER | Yes | No | No | No |
| ITEM_LOC_SOH | Yes | Yes | Yes | No |
| ITEM_LOC | Yes | No | No | No |
This section describes the customer order item subscription service.
When a store is allowed to pick inventory to fulfill a Customer Order, when the inventory of the item ordered does not meet quality standards or is unavailable, then the order indicates that substitutions are allowed for that item. In that case, the store may choose to fulfill the order with a substitute item. If that occurs, SIM has the ability to substitute items on the Customer Order with another predefined Substitute Item.
In such cases, SIM notifies OMS through the SO Status message that an alternative item has been pushed into the order.
Based on the notification from SIM, OMS updates the customer order. OMS notifies RMS with the same details received from SIM so that RMS updates the inventory and customer order details. Based on OMS notification RMS updates the cancelled quantity for the original item and also creates the customer order reservation for the substitute item by updating the customer reserve inventory.
This section describes the package impact.
Package: CustOrdSubstituteServiceProvid
This layer is the entry point for calling the Customer Order Item Substitution webservice. The following operation is available:
createCustOrdSubColDesc (
I_serviceOperationContext IN OUT "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_CustOrdSubColDesc_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_InvocationSuccess_REC"
)
This procedure validates the input service operation context and initializes the output service operation status.
Calls CREATE_CO_SUBSTITUTE to process the Customer Order Item Substitution message.
Any failures (validation errors) encountered during the processing are passed back into the response object. If there are no failures, success status is returned.
Package: SVCPROV_CUSTORDSUB
This layer, called from Web service wrapper, inserts the input business objects into the staging tables and calls the core business logic to process the request. The following operation is available.
CREATE_CO_SUBSTITUTE (O_serviceOperationStatus IN OUT "RIB_ServiceOpStatus_REC",
I_businessObject IN "RIB_CustOrdSubColDesc_REC")
The count of detail message in the input business object is validated against the collection_size to make sure entire message has been received.
The input business object is staged into the staging tables - SVC_CUSTORDSUB and SVC_CUSTORDSUBDTL.
Calls the core business layer CREATE_CO_SUBSTITUTE to process the input item substitution request.
In case of errors received from the core business logic, the error message from the staging table is retrieved and written to the failure table of the output business object.
On successful processing, the processed data from the staging table is deleted.
Core Logic Layer
Package: CORESVC_CUSTORDSUB
The layer implements the core business logic for customer order subscription. The following operation is available.
CREATE_CO_SUBSTITUTE (O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE,
I_process_id IN SVC_CUSTORDSUB.PROCESS_ID%TYPE,
I_chunk_id IN SVC_CUSTORDSUB.CHUNK_ID%TYPE)
The data in the staging table is validated. The header table svc_custordsub is validated first and if there are no errors in the header data then the detail table svc_custordsubdtl gets validated. In case of errors, all the validation errors are written back to the staging table and the function returns back with error.
Post successful validation, the customer order details are updated in ordcust_detail table. The cancelled quantity for the original ordered item is updated. New customer order detail record is created for the substituted item.
The customer reserve bucket in item_loc_soh table is updated by making a call to CUSTOMER_RESERVE_SQL to release the reserved quantity for original item and increase the reserve quantity for the substituted item.
The status in the staging table is updated to 'C'ompleted to indicate successful processing of the data.
Here are the filenames that correspond with each message type. Please consult the RIB documentation for each message type in order to get detailed information of the composition of each message.
| Message Types | Message Type Description | XML Schema Definition (XSD) |
|---|---|---|
| CustOrdSubDesc | Customer Order Substitute Message | CustOrdSubDesc.xsd |
| CustOrdSubColDesc | Collection of Customer Order Substitute Message | CustOrdSubColDesc.xsd |
This section describes the inventory detail lookup service.
This real-time inventory availability lookup facility provided by RMS can be used by external systems, such as an on-line order capture system (OOC) and order management system (OMS), to retrieve item/location inventory based on RMS's view of inventory at a point in time. RMS will provide this information for any warehouse or store which is valid for customer order sourcing/fulfillment via a Web service.
This Web service requires code to abstract the interface logic (service provider layer) from the business processing logic (core layer) and RMS packages will be used by the core layer to perform the actual validations and processing for inventory detail.
This section describes the package impact.
Package: InventoryDetailServiceProvider
This layer is the entry point for the inventory detail lookup Web service. The following operation is available:
lookupInvAvailCriVo(
I_serviceOperationContext IN OUT "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_InvAvailCriVo_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_InvAvailColDesc_REC")
This procedure validates the input service operation context and initializes the output service operation status.
Calls GET_INV_DETAIL to get the inventory details for the input message.
Any failures (validation errors) encountered during the processing are passed back into the response object. If there are no failures, success status is returned.
Package: SVCPROV_INVAVAIL
This layer calls the core business layer to process the inventory lookup request. The following operation is available.
GET_INV_DETAIL(O_ServiceOperationStatus IN OUT "RIB_ServiceOpStatus_REC",
O_business_object OUT "RIB_InvAvailColDesc_REC",
I_business_object IN "RIB_InvAvailCriVo_REC")
Calls the core business layer CORESVC_INVAVAIL to process the inventory detail lookup request.
In case of errors received from the core business logic, the error message is written to the failure table of the output business object.
Package: CORESVC_INVAVAIL
This layer implements the core business logic for inventory detail lookup. The following operation is available.
GET_INV_DETAIL(O_error_message OUT RTK_ERRORS.RTK_TEXT%TYPE,
O_business_object OUT "RIB_InvAvailColDesc_REC",
O_error_tbl OUT SVCPROV_UTILITY.ERROR_TBL,
I_business_object IN "RIB_InvAvailCriVo_REC")
The data in the input business object is validated. If validation errors are encountered, this layer returns the errors in a collection.
The available inventory is fetched from RMS based on the following:
The available quantity is fetched from item_loc_soh as stock_on_hand - SUM of tsf_reserved_qty, customer_resv, rtv_qty and non_sellable_qty.
The warehouse inventory for physical warehouse/channel is only taken for customer orderable stockholding virtual warehouse under it.
If the inventory detail lookup is for a pack item at store, the pack inventory is estimated based on the maximum number of complete packs which can be created by using all the available inventory of its component. The pack_calculate_ind is set to 'Y' to indicate the pack inventory is estimated.
Below are the filenames that correspond with each message type. Please consult the RIB documentation for each message type in order to get a detailed picture of the composition of each message.
| Message Types | Message Type Description | XML Schema Definition (XSD) |
|---|---|---|
| InvDetailCriVo | Inventory Detail Lookup Criteria | InvAvailCriVo.xsd |
| InvAvailDesc | Inventory Detail response Description | InvAvailDesc.xsd |
| InvAvailColDesc | Collection of Inventory Detail Description | InvAvailColDesc.xsd |
Catchweight, Transformable, Consignment, Concession and Deposit container items are not supported for available inventory lookup.
This inventory detail lookup is only for customer orderable inventory.
This section describes the inventory back order subscription API.
Retailers selling through ecommerce channels often take customer orders even if inventory is not available with the expectation of future inventory being available to fill the order. If an order is captured against future inventory the quantity is placed in 'Backordered' status in the external system and a backorder message is sent to RMS through the backorder web service.
This web service will update the backorder quantity in RMS. An external order management system will send backorder reserve requests to RMS when a customer fulfillment is made and backorder release requests when inventory is made available at the fulfillment location.
This section describes the package impact.
Package: InventoryBackOrderServiceProvi
This layer is the entry point for calling the BackOrder. The following operation is available:
createInvBackOrdColDesc(
I_serviceOperationContext IN OUT "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_InvBackOrdColDesc_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_InvocationSuccess_REC"
)
This procedure validates the input service operation context and initializes the output service operation status
Calls CREATE_BACKORDER to process the Backorder message.
Any failures (validation errors) encountered during the processing are passed back into the response object. If there are no failures, success status is returned.
Package: SVCPROV_ INVBACKORD
This layer, called from web service wrapper, inserts the input business objects into the staging tables and calls the core business logic to process the request. The following operation is available.
CREATE_BACKORDER (O_serviceOperationStatus IN OUT "RIB_ServiceOpStatus_REC",
I_businessObject IN "RIB_InvBackOrdColDesc_REC")
The count of detail records in the input business object is validated against the collection_size to make sure entire message has been received.
The input business object is staged into the staging table - SVC_INVBACKORD.
Calls the core business layer CREATE_BACKORDER to process the input backorder request.
In case of errors received from the core business logic, the error message from the staging table is retrieved and written to the failure table of the output business object.
On successful processing, the processed data from the staging table is deleted.
Package: CORESVC_ INVBACKORD
The layer implements the core business logic for backorder subscription. The following operation is available.
CREATE_BACKORDER (O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE,
I_process_id IN SVC_CUSTORDSUB.PROCESS_ID%TYPE,
I_chunk_id IN SVC_CUSTORDSUB.CHUNK_ID%TYPE)
The data in the staging table svc_invbackord is validated. In case of errors, all the validation errors are written back to the staging table and the function returns back with error.
Post successful validation, the backorder details are updated in the item_loc_soh table. The backorder details are updated for both Stores and Warehouses. In case of warehouses, the corresponding virtual warehouses are fetched and the details are updated accordingly.
The customer backorder bucket or pack comp customer backorder bucket in the item_loc_soh table are updated based on the input request item being a regular item or pack item.
In the case of a negative quantity (which indicates backorder release) in the input message, the quantity is subtracted from the customer backorder column in item_loc_soh indicating the release of backorder when the quantity is available in the fulfillment location. In this case also, for warehouses, the corresponding virtual warehouses will be identified from which the quantity has to be released.
An insert is made into inv_resv_update_temp table for a location which has been backordered for the current day. This table is used by inventory extract to AIP to identify the location for which the inventory feed to AIP should be extracted signifying a change in inventory or back order position.
The status in the staging table is updated to 'C'ompleted to indicate successful processing of the data.
Below are the filenames that correspond with each message type. Please consult the RIB documentation for each message type in order to get a detailed picture of the composition of each message.
| Message Types | Message Type Description | XML Schema Definition (XSD) |
|---|---|---|
| InvBackOrdColDesc | Collection of Inventory Backorder Message | InvBackOrdColDesc.xsd |
Catchweight, Transformable, Consignment, Concession and Deposit container items are not supported for backorder requests.
| TABLE | SELECT | INSERT | UPDATE | DELETE |
|---|---|---|---|---|
| SVC_INVBACKORD | Yes | Yes | Yes | Yes |
| INV_RESV_UPDATE_TEMP | Yes | Yes | No | No |
| STORE | Yes | No | No | No |
| WH | Yes | No | No | No |
| CHANNELS | Yes | No | No | No |
| DEPS | Yes | No | No | No |
| UOM_CLASS | Yes | No | No | No |
| ITEM_MASTER | Yes | No | No | No |
| ITEM_LOC | Yes | No | No | No |
| ITEM_LOC_SOH | Yes | No | Yes | No |
| V_PACKSKU_QTY | Yes | No | No | No |
This section describes the customer credit check web service.
RMS provides an interface to update the credit_ind for a franchise customer in RMS. A credit check for the franchisee will be performed before a franchisee order can be approved. Credit_ind is a column in WF_CUSTOMER table. It determines whether customer has a good credit. Valid values are 'Y' and 'N'. For each customer_id/customer_group_id combination, the credit_ind should be updated in the WF_CUSTOMER table. RMS supports Web service for processing Customer Credit Check message from external financial application. RMS exposes a 'CustCreditcheckservice' Web service to update the credit_ind. An external financial application will invoke the service with input collection to update the credit_ind in RMS table.
Accepts a collection of input parameters. The input is a collection of customer_id, customer_group_id and credit_ind. For each customer_id/customer_group_id combination, the credit_ind should be updated in the WF_CUSTOMER table.
RMS returns failure status as part of the response object in the Web service call if credit_ind is not updated due to validation errors.
Filename: CustCreditCheckServiceProviderImplSpec and
CustCreditCheckServiceproviderImplBody
The Web service 'CustomerCreditCheckService' with an operation of 'updateCustCredit' is available for external financial application to send update request for credit_ind to RMS. The Web service invokes the public interface 'CreateCustCreditChkColDesc' (CustCreditCheckServiceProviderImpl.CreateCustCreditChkColDesc).
The input is a collection of customer_id, customer_group_id and credit_ind. For each customer_id/customer_group_id combination, the credit_ind should be updated in the WF_CUSTOMER table. This public interface will call svcprov_context.set_svcprov_context and svcprov_custcreditchk.create_credit_ind to update the credit_ind in WF_CUSTOMER table. The messages are staged, validated and persisted to RMS using the core functions. At the end of the processing, the staging tables are purged and a confirmation status is returned.
The flowchart below illustrates the complete process:
This section describes the store order subscription API.
The Web service provided by RMS is used by external systems, such as SIM to perform the following:
Create, Modify, and Delete a Store Order (PO or Transfer) details in RMS.
Retrieve Item Sales information for Store and Item.
Retrieve Deals information for Store and Item.
Retrieve Store Orders (PO or Transfers) for the Store.
Retrieve details of Store Order (PO or Transfer).
The Store Order Web service replaces the service interface based on RSL .This Web service requires code to abstract the interface logic (service provider layer) from the business processing logic (core layer), which uses RMS packages to perform the processing for a requested operations.
This section describes the package impact.
Package: StoreOrderServiceProviderImpl
This layer is the entry point for the Store Order Web service. The following available operations are:
createLocPOTsfDesc(
I_serviceOperationContext IN OUT "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_LocPOTsfDesc_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_LocPOTsfRef_REC")
This procedure validates the input service operation context and initializes the output service operation status.
Calls SVCPROV_STOREORDER.CREATE_LOC_PO_TSF for creating the Store Order (PO or Transfer) details.
The generated order number is returned in the O_businessObject.
Any failures (validation errors) encountered during the processing are passed back into the ServiceOpStatus response object. If there are no failures, success status is returned through ServiceOpStatus.
deleteLocPOTsfDesc(
I_serviceOperationContext IN OUT "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_LocPOTsfDesc_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_InvocationSuccess_REC")
This procedure validates the input service operation context and initializes the output service operation status.
Calls SVCPROV_STOREORDER.DELETE_LOC_PO_TSF for deleting the Store Order (PO or Transfer) details.
Any failures (validation errors) encountered during the processing are passed back to the ServiceOpStatus response object. If there are no failures, success status is returned through ServiceOpStatus.
modifyLocPOTsfDesc(
I_serviceOperationContext IN OUT "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_LocPOTsfDesc_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_InvocationSuccess_REC")
This procedure validates the input service operation context and initializes the output service operation status.
Calls SVCPROV_STOREORDER.MOD_LOC_PO_TSF for modifying of the Store Order (PO or Transfer) details.
Any failures (validation errors) encountered during the processing are passed back into the ServiceOpStatus response object. If there are no failures, success status is returned through ServiceOpStatus.
createDetailLocPOTsfDesc(
I_serviceOperationContext IN OUT "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_LocPOTsfDesc_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_InvocationSuccess_REC")
This procedure validates the input service operation context and initializes the output service operation status.
Calls SVCPROV_STOREORDER.CREATE_LOC_PO_TSF_DETAIL for creating the Store Order (PO or Transfer) details.
Any failures (validation errors) encountered during the processing are passed back into the ServiceOpStatus response object. If there are no failures, success status is returned through ServiceOpStatus.
deleteDetailLocPOTsfDesc(
I_serviceOperationContext IN OUT "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_LocPOTsfDesc_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_InvocationSuccess_REC")
This procedure validates the input service operation context and initializes the output service operation status.
Calls SVCPROV_STOREORDER. DELETE_LOC_PO_TSF_DETAIL for deleting of Store Order (PO or Transfer) details.
Any failures (validation errors) encountered during the processing are passed back into the ServiceOpStatus response object. If there are no failures, success status is returned through ServiceOpStatus.
modifyDetailLocPOTsfDesc(
I_serviceOperationContext IN OUT "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_LocPOTsfDesc_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_InvocationSuccess_REC")
This procedure validates the input service operation context and initializes the output service operation status.
Calls SVCPROV_STOREORDER.MOD_LOC_PO_TSF_DETAIL for modification of Store Order (PO or Transfer) details.
Any failures (validation errors) encountered during the processing are passed back into the ServiceOpStatus response object. If there are no failures, success status is returned through ServiceOpStatus.
queryDeal(
I_serviceOperationContext IN OUT "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_LocPOTsfDealsCriVo_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_LocPOTsfDealsColDesc_REC")
This procedure validates the input service operation context and initializes the output service operation status
Calls SVCPROV_STOREORDER.QUERY_LOC_PO_TSF_DEALS for retrieving the deals information which is returned to the O_businessObject.
Any failures (validation errors) encountered during the processing are passed back into the ServiceOpStatus response object. If there are no failures, success status is returned through ServiceOpStatus.
queryItemSales(
I_serviceOperationContext IN OUT "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_LocPOTsfItmSlsCriVo_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_LocPOTsfItmSlsColDesc_REC")
This procedure validates the input service operation context and initializes the output service operation status.
Calls SVCPROV_STOREORDER.QUERY_LOC_PO_TSF_ITEMSALES for retrieving the item sales information which is returned to the O_businessObject.
Any failures (validation errors) encountered during the processing are passed back into the ServiceOpStatus response object. If there are no failures, success status is returned through ServiceOpStatus.
queryStoreOrder (
I_serviceOperationContext IN OUT "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_LocPOTsfHdrCriVo_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_LocPOTsfHdrColDesc_REC")
This procedure validates the input service operation context and initializes the output service operation status.
Calls SVCPROV_STOREORDER.QUERY_LOC_PO_TSF_HEADER for retrieving the store orders (PO, Transfer) .This will be returned in the O_businessObject.
Any failures (validation errors) encountered during the processing are passed back into the ServiceOpStatus response object. If there are no failures, success status is returned through ServiceOpStatus.
queryStoreOrderDetail (
I_serviceOperationContext IN OUT "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_LocPOTsfDtlsCriVo_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_LocPOTsfDesc_REC")
This procedure validates the input service operation context and initializes the output service operation status.
Calls SVCPROV_STOREORDER.QUERY_LOC_PO_TSF_DETAIL for retrieving the details of the store orders (PO, Transfer) .This will be returned in the O_businessObject.
Any failures (validation errors) encountered during the processing are passed back into the ServiceOpStatus response object. If there are no failures, success status is returned through ServiceOpStatus.
Package: SVCPROV_STOREORDER
This layer calls the core business layer to process the requests. The following operations are available.
CREATE_LOC_PO_TSF(
O_serviceOperationStatus IN OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_LocPOTsfRef_REC",
I_businessObject IN "RIB_LocPOTsfDesc_REC")
Calls the function CREATE_MOD_LOCPO in the core business layer CORESVC_STOREORDER to process the Store Order creation request.
In case of errors received from the core business logic, the error message is written to the failure table of the O_serviceOperationStatus object.
CREATE_LOC_PO_TSF_DETAIL(
O_serviceOperationStatus IN OUT "RIB_ServiceOpStatus_REC",
I_businessObject IN "RIB_LocPOTsfDesc_REC")
Calls the function CREATE_MOD_LOCPO in the core business layer CORESVC_STOREORDER to process the Store Order Details creation request.
In case of errors received from the core business logic, the error message is written to the failure table of the O_serviceOperationStatus object.
MOD_LOC_PO_TSF(
O_serviceOperationStatus IN OUT "RIB_ServiceOpStatus_REC",
I_businessObject IN "RIB_LocPOTsfDesc_REC")
Calls the function CREATE_MOD_LOCPO in the core business layer CORESVC_STOREORDER to process the Store Order Modification request.
In case of errors received from the core business logic, the error message is written to the failure table of the O_serviceOperationStatus object.
MOD_LOC_PO_TSF_DETAIL(
O_serviceOperationStatus IN OUT "RIB_ServiceOpStatus_REC",
I_businessObject IN "RIB_LocPOTsfDesc_REC")
Calls the function CREATE_MOD_LOCPO in the core business layer CORESVC_STOREORDER to process the Store Order details modification request.
In case of errors received from the core business logic, the error message is written to the failure table of the O_serviceOperationStatus object.
DELETE_LOC_PO_TSF(
O_serviceOperationStatus IN OUT "RIB_ServiceOpStatus_REC",
I_businessObject IN "RIB_LocPOTsfDesc_REC")
Calls the function DEL_LOCPO in the core business layer CORESVC_STOREORDER to process the Store Order deletion request.
In case of errors received from the core business logic, the error message is written to the failure table of the O_serviceOperationStatus object.
DELETE_LOC_PO_TSF_DETAIL(
O_serviceOperationStatus IN OUT "RIB_ServiceOpStatus_REC",
I_businessObject IN "RIB_LocPOTsfDesc_REC")
Calls the function DEL_LOCPO in the core business layer CORESVC_STOREORDER to process the Store Order Details deletion request.
In case of errors received from the core business logic, the error message is written to the failure table of the O_serviceOperationStatus object.
QUERY_LOC_PO_TSF_DEALS(
O_serviceOperationStatus IN OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_LocPOTsfDealsColDesc_REC",
I_businessObject IN "RIB_LocPOTsfDealsCriVo_REC")
Calls the function GET_DEALS in the core business layer CORESVC_STOREORDER to process the Deals query request.
In case of errors received from the core business logic, the error message is written to the failure table of the O_serviceOperationStatus object.
QUERY_LOC_PO_TSF_ITEMSALES(
O_serviceOperationStatus IN OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_LocPOTsfItmSlsColDesc_REC",
I_businessObject IN "RIB_LocPOTsfItmSlsCriVo_REC")
Calls the function GET_ITEMS_SALES in the core business layer CORESVC_STOREORDER to process the Item Sales retrieval request.
In case of errors received from the core business logic, the error message is written to the failure table of the O_serviceOperationStatus object.
QUERY_LOC_PO_TSF_HEADER (
O_serviceOperationStatus IN OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_LocPOTsfRef_REC",
I_businessObject IN "RIB_LocPOTsfDesc_REC")
Calls the function GET_STORE_ORDERS in the core business layer CORESVC_STOREORDER to process the Store Orders retrieval request.
In case of errors received from the core business logic, the error message is written to the failure table of the O_serviceOperationStatus object.
QUERY_LOC_PO_TSF_DETAIL(
O_serviceOperationStatus IN OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_LocPOTsfDesc_REC",
I_businessObject IN "RIB_LocPOTsfDtlsCriVo_REC")
Calls the function GET_STORE_ORDER_DETAILS in the core business layer CORESVC_STOREORDER to process the Store Order Details retrieval request.
In case of errors received from the core business logic, the error message is written to the failure table of the O_serviceOperationStatus object.
Package: CORESVC_STOREORDER
This layer implements the core business logic for Store Order operations. The following operations are available:
CREATE_MOD_LOCPO( IO_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_locpotsfref_rec OUT NOCOPY "RIB_LocPOTsfRef_REC", I_locpodesc_rec IN "RIB_LocPOTsfDesc_REC", I_action IN VARCHAR2) RETURN BOOLEAN
This function is used to Create, Modify Transfer/ PO header and details based on the input action_type. It performs input payload validation and calls RMSSUB_XORDER or RMSSUB_XTSF APIs to achieve it.
The encountered error will be returned on IO_error_message.
For a create operation, the generated order_no or tsf_no will be returned as the order_id in the LocPOTsfRef object.
DEL_LOCPO( IO_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, I_locpotsfdesc_rec IN "RIB_LocPOTsfDesc_REC", I_action IN VARCHAR2) RETURN BOOLEAN
The function is used to delete transfer/PO header and details based on the input action_type. It performs input payload validation and calls RMSSUB_XORDER or RMSSUB_XTSF APIs to achieve it.
The encountered error will be returned on O_error_message.
GET_DEALS( IO_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_locpotsfdealscoldesc_rec OUT NOCOPY "RIB_LocPOTsfDealsColDesc_REC", I_locpotsfdealscrivo_rec IN "RIB_LocPOTsfDealsCriVo_REC") RETURN BOOLEAN
This function retrieves all applicable deals information for the input item/store.
The encountered error will be returned on O_error_message.
GET_ITEMS_SALES( IO_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_locpotsfitmslscoldesc_rec OUT NOCOPY RIB_LocPOTsfItmSlsColDesc_REC", I_locpoitmslsreq_rec IN "RIB_LocPOTsfItmSlsCriVo_REC") RETURN BOOLEAN
This function retrieves the item sales information for the input item/store.
The encountered error is returned on O_error_message.
GET_STORE_ORDERS( IO_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_locpotsfhdrcoldesc_rec OUT NOCOPY "RIB_LocPOTsfHdrColDesc_REC", I_locpotsfhdrcrivo_rec IN "RIB_LocPOTsfHdrCriVo_REC") RETURN BOOLEAN
The function retrieves all relevant store orders (POs and transfers) for the input store/item contained in the input business object.
The encountered error is returned on O_error_message.
GET_STORE_ORDER_DETAILS( IO_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE, O_locpotsfdesc_rec OUT NOCOPY "RIB_LocPOTsfDesc_REC", I_locpotsfdtlscrivo_rec IN "RIB_LocPOTsfDtlsCriVo_REC") RETURN BOOLEAN
This is used to retrieve the store order details for the input store, order_no or tsf_no contained in the input business object.
The encountered error is returned on O_error_message.
Below are the filenames that correspond with each message type. Please consult the RIB documentation for each message type in order to get a detailed picture of the composition of each message.
| Message Types | Message Type Description | XML Schema Definition (XSD) |
|---|---|---|
| LocPOTsfDesc | Location PO Transfer Description | LocPOTsfDesc.xsd |
| LocPOTsfRef | Location PO Transfer Reference | LocPOTsfRef.xsd |
| LocPOTsfHdrCriVo | Location PO Transfer Header query Criteria | LocPOTsfHdrCriVo.xsd |
| LocPOTsfHdrDesc | Location PO Transfer Header Description | LocPOTsfHdrDesc.xsd |
| LocPOTsfHdrColDesc | Collection of Location PO Transfer Header Description | LocPOTsfHdrColDesc.xsd |
| LocPOTsfDtlsCriVo | Location PO Transfer Details query criteria | LocPOTsfDtlsCriVo.xsd |
| LocPOTsfDealsCriVo | Location PO Transfer Deals query Criteria | LocPOTsfDealsCriVo.xsd |
| LocPOTsfDealsDesc | Location PO Transfer Deals Description | LocPOTsfDealsDesc.xsd |
| LocPOTsfDealsColDesc | Collection of Location PO Transfer Deals Description | LocPOTsfDealsColDesc.xsd |
| LocPOTsfItmSlsCriVo | Location PO Transfer Item Sales query Criteria | LocPOTsfItmSlsCriVo.xsd |
| LocPOTsfItmSlsDesc | Location PO Transfer Item Sales Description | LocPOTsfItmSlsDesc.xsd |
| LocPOTsfItmSlsColDesc | Collection of Location PO Transfer Item Sales Description | LocPOTsfItmSlsColDesc.xsd |
To minimize the development and testing effort, no staging tables have been used to stage the data.
Instead of following the pattern of VALIDATE/ POPULATE/ PERSIST, existing package logic has been reused in the core business layer.
Instead of returning with all the validation errors found, package will just return back the first error encountered.
| TABLE | SELECT | INSERT | UPDATE | DELETE |
|---|---|---|---|---|
| ORDHEAD | Yes | Yes | Yes | No |
| ORDLOC | Yes | Yes | Yes | Yes |
| ORDSKU | Yes | Yes | Yes | Yes |
| TSFHEAD | Yes | Yes | Yes | No |
| TSFDETAIL | Yes | Yes | Yes | Yes |
| ITEM_LOC_HIST | Yes | No | No | No |
| DEAL_HEAD | Yes | No | No | No |
| DEAL_DETAIL | Yes | No | No | No |
| DEAL_THRESHOLD | Yes | No | No | No |
| ITEM_MASTER | Yes | No | No | No |
| STORE | Yes | No | No | No |
| WH | Yes | No | No | No |
This section describes the item number reservation serice API.
The Item Number Reservation web service allows external systems such as Oracle Retail Assortment Planning (AP) or Oracle Retail Category Management to reserve item numbers in RMS. This web service contains the following details:
Item number type
Quantity
Days until expiry
The web service validates that the item number type passed is a valid number type in RMS that supports auto generation of item numbers and that the days until expiry is greater than zero.
Once validated, RMS should auto generate the requested quantity of item numbers of the specified type and store them in a reservation log table that tracks their usage and expiry. The columns in the reservation log table would include the following:
Item number type
Item number
Expiry date = vdate when request is received+ Days until expiry
The following are the only valid item number types:
ITEM
UPC-A
UPC-AS
EAN13
The details inserted into the reservation log for every valid web service call are also sent back as part of the web service response to inform the calling application that the reservation was successful and the numbers reserved. These pre-reserved numbers should not be considered for any auto-generated item numbers in RMS. If a user keys in a pre-reserved item number while creating a new item, the system should stop the user from proceeding by displaying an appropriate message indicating that this number is already reserved.
The structure of the Item Number Reservation message family is the following:
"RIB_ItemNumCriVo_REC" (input)
-- item_number_type
-- quantity
-- expiry_days
"RIB_ItemNumColDesc_REC" (output)
-- collection size
-- ItemNumDesc_TBL
"RIB_ItemNumDesc_REC"
-- item
-- item_number_type
This section describes the package impact.
Filename: ItemManagementServiceProviderImplSpec/Body.sql
PROCEDURE reserveItemNumber(I_serviceOperationContext IN OUT "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_ItemNumCriVo_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_ItemNumColDesc_REC")
This will call the Item Reservation Package - CORESVC_ITEM_RESERVE_SQL.RESERVE_ITEM_NUMBER().
Filename: Coresvc_itemreserveb/s.pls
RESERVE_ITEM_NUMBER(O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE,
O_businessObject IN OUT "RIB_ItemNumColDesc_REC",
I_serviceOperationContext IN "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_ItemNumCriVo_REC")
This package will be called by the webservice to accept reservation requests that contain the following details:
Item number type
Quantity
Days until expiry
The VALIDATE_FIELDS() checks if all the required fields are entered, calls the CHECK_ITEM_NUMBER_TYPE() and validate if the days until expiry is greater than zero. This function will validate whether the item number passed is a valid number type that supports auto generation of item numbers. Any invalid records will be errored-out.
If the record is valid, item numbers will be generated depending on the item number type passed by calling the ITEM_NUMBER_TYPE_SQL.GET_NEXT() function. This call will be looped depending on the quantity given.
The POPULATE_ITEM_RESERVE function will insert any valid records into the reservation log table (SVC_ITEM_RESERVATION).
Below are the filenames that correspond with each message type. Please consult the RIB documentation for each message type in order to get a detailed picture of the composition of each message.
| Message Types | Message Type Description | XML Schema Definition (XSD) |
|---|---|---|
| reserveItemNumber | Item Number Reservation | ItemNumCriVo.xsd |
This section describes the order management service API.
The Order Management web service allows the external systems to accept requests to generate pre-issued order numbers in RMS. This web service will contain the following details:
Supplier ID (if the requesting entity is a vendor)
Quantity (number of pre-issued order numbers requested)
Days until expiry
The web service validates that the supplier number passed is valid and active in RMS and that the days until expiry and quantity are both greater than zero.
Once validated, RMS generates the requested quantity of pre-issued order numbers and stores them in an existing RMS table that tracks their usage and expiry. The columns in the base table include:
Order number
Supplier number
Expiry date = vdate when request is received + Days until expiry
The details inserted into the base table for every valid web service call would also be sent back as part of the web service response to inform the calling application that the request was successful. The numbers generated will also be sent back to the calling application.
Below are the structures of the objects used in the new Purchase Order Number web service:
"RIB_OrdNumCriVo_REC" (input)
-- supplier number(10)
-- quantity number(4)
-- expiry_days number(4)
"RIB_OrdNumColDesc_REC" (output)
-- collection size
-- OrdNumDesc_TBL RIB_OrdNumDesc_TBL
"RIB_OrdNumDesc_REC"
-- supplier number(10)
-- order_no number(8)
-- expiry_date date
This section describes the package impact.
Filename: OrderManagementServiceProviderImplSpec/Body.sql
PROCEDURE preIssueOrderNumber(I_serviceOperationContext IN OUT "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_OrdNumCriVo_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_OrdNumColDesc_REC")
This will call the Order PreIssue Request Package - CORESVC_ORD_PREISSUE_SQL.GENERATE_ORDER_NOS().
Filename: Coresvc_ordpreisb/s.pls
GENERATE_ORDER_NOS(O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE,
O_businessObject IN OUT "RIB_OrdNumColDesc_REC",
I_serviceOperationContext IN "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_OrdNumCriVo_REC")
This package is called by the webservice to accept requests that contain the following details:
Supplier ID
Quantity
Days until expiry
The function checks if all the required fields are present and validates if the days until expiry and quantity are greater than zero. This function also validates whether the supplier ID passed is valid and is an active supplier. Any invalid records will be errored-out.
If the record is valid, pre-issued order numbers are generated - by calling the ORDER_NUMBER_SQL.PREISSUE() function. The PREISSUE function is responsible for inserting the specified number of order numbers into the ORD_PREISSUE table.
Filename: Ordnumb/s.pls
PREISSUE(O_error_message IN OUT RTK_ERRORS.RTK_TEXT%TYPE,
O_ordnum_rec IN OUT "RIB_OrdNumColDesc_REC",
I_qty IN NUMBER,
I_expiry_date IN ORD_PREISSUE.EXPIRY_DATE%TYPE,
I_supplier IN ORD_PREISSUE.SUPPLIER%TYPE,
I_create_id IN ORD_PREISSUE.CREATE_ID %TYPE)
This function is called within the new package CORESVC_ORD_PREISSUE_SQLto accept requests that contain the following details:
Quantity
Days until expiry
Supplier ID
Create ID
The new overloaded function PREISSUE has an additional OUT parameter "RIB_OrdNumColDesc_REC". It is responsible for generating new order numbers via a call to ORDER_NUMBER_SQL.NEXT_ORDER_NUMBER. The generated order numbers are then inserted into the base RMS table (ORD_PREISSUE). It also populates the "RIB_OrdNumColDesc_REC" record that holds a collection of order numbers generated for the given supplier number. This collection will be returned to the calling application.
Here are the filenames that correspond to each message type. Please consult the RIB documentation for each message type in order to get a detailed picture of the composition of each message.
| Message Types | Message Type Description | XML Schema Definition (XSD) |
|---|---|---|
| preIssueOrderNumber | Pre-issued Order Number Generation | OrdNumCriVo.xsd |
This section described the Average Cost Subscription API.
RMS provides a SOAP web service to support the update of weighted average cost from an external system to Merchandising for one or more item/location combinations. It also creates a tran data record posting with tran code 70.The web service will be called with the following details:
The web service will contain the following details.
Item
Location
Location Type
New Avg Cost (must be greater than 0)
This section describes the package impact.
Filename: AverageCostServiceProviderImplSpec/Body.sql
modifyAvgCost(I_serviceOperationContext IN OUT "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_ItLocAgCstColDesc_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_InvocationSuccess_REC");
/*********
This will call the SVC provider Package - SVCPROV_AVGCOST_SQL.UPD_AVG_COST.
Filename: svcprov_avgcostb/s.pls
PROCEDURE
UPD_AVG_COST(O_ServiceOperationStatus IN OUT "RIB_ServiceOpStatus_REC",
O_businessObject IN OUT "RIB_InvocationSuccess_REC",
I_business_object IN "RIB_ItLocAgCstColDesc_REC");
This procedure calls the core package CORESVC_AVGCOST_SQL.UPD_AVG_COST.
If error happens, it calls SVCPROV_UTILITY. PARSE_ERR_MSG to build and return "RIB_ServiceOpStatus_REC"with a failure message; if no errors, it builds and returns "RIB_InvocationSuccess_REC" with a success message.
Filename: coresvc_avgcostb/s.pls
FUNCTION UPD_AVG_COST(O_error_message OUT RTK_ERRORS.RTK_TEXT%TYPE,
O_error_tbl OUT SVCPROV_UTILITY.ERROR_TBL,
I_business_object IN "RIB_ItLocAgCstColDesc_REC")
This is the main function which validates the input and updates the new Avg cost.
All the input fields are mandatory.
Checks for Valid Item/Loc combination.
The avg cost must be greater than zero.
If the input is/are valid, the new avg cost will be updated for the given item/loc combination and a tran data posting will be recorded with tran code 70.
Here are the filenames that correspond with each message type. Please consult the RIB documentation for each message type in order to get a detailed picture of the composition of each message.
| Operation Types | Operation Type Description | XML Schema Definition (XSD) |
|---|---|---|
| modifyAvgCost | Modify Average Cost Service Operation | ItLocAgCstColDesc.xsdItLocAgCstDesc.xsd |
This section describes the Diff Management Service API.
This service was created by SOAP to enable the existing Diff Subscription API to support creating, updating, or deleting Diff Ids and Diff Groups in Merchandising.
This layer is the entry point for the diff management Web service. The following operation is available:
PROCEDURE createDiffId(I_serviceOperationContext IN OUT "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_XDiffIDColDesc_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_InvocationSuccess_REC")
This procedure validates the input service operation context and initializes the output service operation status.
Calls CREATE_DIFF_ID to create the Diff id for the input message.
Any failures (validation errors) encountered during the processing are passed back into the response object. If there are no failures, success status is returned.
PROCEDURE modifyDiffId(
I_serviceOperationContext IN OUT "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_XDiffIDColDesc_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_InvocationSuccess_REC")
This procedure validates the input service operation context and initializes the output service operation status.
Calls MODIFY_DIFF_ID to modify the Diff id for the input message.
Any failures (validation errors) encountered during the processing are passed back into the response object. If there are no failures, success status is returned.
PROCEDURE deleteDiffId(I_serviceOperationContext IN OUT "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_XDiffIDColRef_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_InvocationSuccess_REC")
This procedure validates the input service operation context and initializes the output service operation status.
Calls DELETE_DIFF_ID to delete the Diff id for the input message.
Any failures (validation errors) encountered during the processing are passed back into the response object. If there are no failures, success status is returned.
PROCEDURE createDiffGrp(I_serviceOperationContext IN OUT "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_XDiffGrpColDesc_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_InvocationSuccess_REC")
This procedure validates the input service operation context and initializes the output service operation status.
Calls CREATE_DIFF_GROUP to create the Diff group for the input message.
Any failures (validation errors) encountered during the processing are passed back into the response object. If there are no failures, success status is returned.
PROCEDURE modifyDiffGrp(I_serviceOperationContext IN OUT "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_XDiffGrpColDesc_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_InvocationSuccess_REC")
This procedure validates the input service operation context and initializes the output service operation status.
Calls MODIFY_DIFF_GROUP to modify the Diff group for the input message.
Any failures (validation errors) encountered during the processing are passed back into the response object. If there are no failures, success status is returned.
PROCEDURE deleteDiffGrp(I_serviceOperationContext IN OUT "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_XDiffGrpColRef_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_InvocationSuccess_REC")
This procedure validates the input service operation context and initializes the output service operation status.
Calls DELETE_DIFF_GROUP to delete the diff groups for the input message.
Any failures (validation errors) encountered during the processing are passed back into the response object. If there are no failures, success status is returned.
PROCEDURE createDiffGrpDtl(I_serviceOperationContext IN OUT "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_XDiffGrpColDesc_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_InvocationSuccess_REC")
This procedure validates the input service operation context and initializes the output service operation status.
Calls CREATE_DIFF_GROUP_DTL to create the Diff group details for the input message.
Any failures (validation errors) encountered during the processing are passed back into the response object. If there are no failures, success status is returned.
PROCEDURE modifyDiffGrpDtl(I_serviceOperationContext IN OUT "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_XDiffGrpColDesc_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_InvocationSuccess_REC")
This procedure validates the input service operation context and initializes the output service operation status.
Calls MODIFY_DIFF_GROUP_DTL to modify the Diff group details for the input message.
Any failures (validation errors) encountered during the processing are passed back into the response object. If there are no failures, success status is returned.
PROCEDURE deleteDiffGrpDtl(I_serviceOperationContext IN OUT "RIB_ServiceOpContext_REC",
I_businessObject IN "RIB_XDiffGrpColRef_REC",
O_serviceOperationStatus OUT "RIB_ServiceOpStatus_REC",
O_businessObject OUT "RIB_InvocationSuccess_REC")
This procedure validates the input service operation context and initializes the output service operation status.
Calls DELETE_DIFF_GROUP_DTL to delete the Diff group details for the input message.
Any failures (validation errors) encountered during the processing are passed back into the response object. If there are no failures, success status is returned.
This layer calls the core business layer to process the diff id request. The following operation is available.
PROCEDURE CREATE_DIFF_ID(O_serviceOperationStatus IN OUT "RIB_ServiceOpStatus_REC", O_businessObject IN OUT "RIB_InvocationSuccess_REC", I_serviceOperationContext IN "RIB_ServiceOpContext_REC", I_businessObject IN "RIB_XDiffIDColDesc_REC")PROCEDURE MODIFY_DIFF_ID(O_serviceOperationStatus IN OUT "RIB_ServiceOpStatus_REC", O_businessObject IN OUT "RIB_InvocationSuccess_REC", I_serviceOperationContext IN "RIB_ServiceOpContext_REC", I_businessObject IN "RIB_XDiffIDColDesc_REC")PROCEDURE DELETE_DIFF_ID(O_serviceOperationStatus IN OUT "RIB_ServiceOpStatus_REC", O_businessObject IN OUT "RIB_InvocationSuccess_REC", I_serviceOperationContext IN "RIB_ServiceOpContext_REC", I_businessObject IN "RIB_XDiffIDColRef_REC" )
All the above package calls the core business layer RMSSUB_XDIFFID.CONSUME to process the diff ID request.
In case of errors received from the core business logic, the error message is written to the failure table of the output business object.
PROCEDURE CREATE_DIFF_GROUP(O_serviceOperationStatus IN OUT "RIB_ServiceOpStatus_REC", O_businessObject IN OUT "RIB_InvocationSuccess_REC", I_serviceOperationContext IN "RIB_ServiceOpContext_REC", I_businessObject IN "RIB_XDiffGrpColDesc_REC")PROCEDURE MODIFY_DIFF_GROUP(O_serviceOperationStatus IN OUT "RIB_ServiceOpStatus_REC", O_businessObject IN OUT "RIB_InvocationSuccess_REC", I_serviceOperationContext IN "RIB_ServiceOpContext_REC", I_businessObject IN "RIB_XDiffGrpColDesc_REC")PROCEDURE DELETE_DIFF_GROUP(O_serviceOperationStatus IN OUT "RIB_ServiceOpStatus_REC", O_businessObject IN OUT "RIB_InvocationSuccess_REC", I_serviceOperationContext IN "RIB_ServiceOpContext_REC", I_businessObject IN "RIB_XDiffGrpColRef_REC")PROCEDURE CREATE_DIFF_GROUP_DTL(O_serviceOperationStatus IN OUT "RIB_ServiceOpStatus_REC", O_businessObject IN OUT "RIB_InvocationSuccess_REC", I_serviceOperationContext IN "RIB_ServiceOpContext_REC", I_businessObject IN "RIB_XDiffGrpColDesc_REC")PROCEDURE MODIFY_DIFF_GROUP_DTL(O_serviceOperationStatus IN OUT "RIB_ServiceOpStatus_REC", O_businessObject IN OUT "RIB_InvocationSuccess_REC", I_serviceOperationContext IN "RIB_ServiceOpContext_REC", I_businessObject IN "RIB_XDiffGrpColDesc_REC")PROCEDURE DELETE_DIFF_GROUP_DTL(O_serviceOperationStatus IN OUT "RIB_ServiceOpStatus_REC", O_businessObject IN OUT "RIB_InvocationSuccess_REC", I_serviceOperationContext IN "RIB_ServiceOpContext_REC", I_businessObject IN "RIB_XDiffGrpColRef_REC")
All the above package calls the core business layer RMSSUB_XDIFFGRP.CONSUME to process the diff group request.
In case of errors received from the core business logic, the error message is written to the failure table of the output business object.
Here are the filenames that correspond to each message type. Please consult the RIB documentation for each message type to get a detailed picture of the composition of each message.
| Message Types | Message Type Description | XML Schema Definition (XSD) |
|---|---|---|
| createDiffId | Create Diff Ids | XDiffIDColDesc.xsd |
| deleteDiffId | Delete Diff Ids | XDiffIDColRef.xsd |
| modifyDiffId | Modify Diff Ids | XDiffIDColDesc.xsd |
| createDiffGrpDtl | Create diff group details | XDiffGrpColDesc.xsd |
| deleteDiffGrpDtl | Delete diff group details | XDiffGrpColRef.xsd |
| modifyDiffGrpDtl | Modify diff group details | XDiffGrpColDesc.xsd |
| createDiffGrp | Create diff group headers | XDiffGrpColDesc.xsd |
| deleteDiffGrp | Delete entire diff groups | XDiffGrpColRef.xsd |
| modifyDiffGrp | Modify diff group headers | XDiffGrpColDesc.xsd |
| createDiffId | Collection of external Diff IDs for create | XDiffIDColDesc.xsd |
| deleteDiffId | Collection of Diff Ids for delete | XDiffIDColRef.xsd |
