| Oracle® Application Integration Architecture Oracle Financial Operations Control Integration Pack Implementation Guide for Oracle Retail Merchandise Operations Management and PeopleSoft Enterprise Financials Release 3.1 Part Number E20500-03 |
|
|
PDF · Mobi · ePub |
This chapter discusses the lifecycle management for reference data, including currency exchange rate, payment term, and suppliers information process integrations.
This chapter includes the following sections:
This section provides an overview of the process integration for initial loading and incremental synchronization of currency exchange rates between PeopleSoft General Ledger (GL) and the Oracle Retail Merchandising System (Oracle RMS) and discusses the following topics:
Currency exchange rate is the reference information used in the translation of monetary values from one currency to another. The exchange rate expresses the value of one currency in terms of another. The process integration for currency exchange rates enables you to use PeopleSoft Financials as an accounting engine and Oracle Retail for sales audit and stock ledger transactions.
The process integration for currency exchange rates supports these integration flows:
Load initial currency exchange rate from PeopleSoft GL to Oracle RMS
Enables the loading of all current effective-dated currency exchange rates from PeopleSoft GL to Oracle RMS for a new instance (logical or physical) of Oracle RMS
Incremental creation and updates of currency exchange rates from PeopleSoft GL to Oracle RMS
Enables the synchronization of incremental creation and updates of the current effective-dated currency exchange rates from PeopleSoft GL to Oracle RMS
This integration is not a point-to-point integration between PeopleSoft GL and Oracle RMS. An Oracle Application Integration Architecture (Oracle AIA) layer serves as an intermediate thin layer of application between PeopleSoft GL and Oracle RMS. As part of the currency exchange rate integration, PeopleSoft GL sends the currency exchange rates to the Oracle AIA layer, and the Oracle AIA layer delivers the information to Oracle RMS. The Oracle AIA layer performs message filtering, message transformation, and message routing.
The integration design assumes that:
The PeopleSoft Financial Management system is responsible for adding and maintaining the currency exchange rates and types.
The PeopleSoft Financial Management system is the system of record.
The currency rate types are different in PeopleSoft and Oracle Retail applications.
The domain value maps (DVMs) are set up and maintained by both PeopleSoft GL and the Oracle AIA layer. Together, the COMMON value is found.
For initial synchronization, the Oracle Retail system date is set to match the PeopleSoft system date.
When initial synchronization is complete, Oracle Retail can restore the system date.
After the PeopleSoft currency exchange rates are published, the current effective-dated currency exchange rates are synchronized with the Oracle Retail exchange rates.
Oracle Retail accepts all records from PeopleSoft except the records with previous dates (before their vdate).
The PeopleSoft application maintains a table that stores effective-dated rate changes.
The PeopleSoft application supports triangulation of currency exchange rates, but Oracle Retail does not.
The PeopleSoft application converts its rates to a common rate before calling the web service for integration.
Retail RIB Error Hospital holds all the Oracle Retail side errors and handles any notification on its side.
If a value is not present for Oracle Retail in the CURRENCYEXCHANGE_CONVERSIONTYPECODE DVM, the Oracle AIA layer filters the record and does not send it to Oracle Retail.
The system sends a message to inform users that the value used for this DVM is not in the DVM. No error is generated.
If the value is missing for the CURRENCY_CODE DVM, the Oracle AIA layer passes the record to Oracle Retail with the PeopleSoft values.
No error is generated.
Oracle Retail accepts only those currency exchange rates for which the from_currency is the base currency and ignores other exchange rates.
Oracle Retail handles this action internally. The AIA layer does not filter exchange rates.
Figure 2-1 illustrates the currency exchange rate integration flow.
The integration flow uses these services:
CurrencyExchangePeopleSoftJMSConsumer
SyncCurrencyExchangeListPeopleSoftReqABCSImpl
CurrencyExchangeEBS
SyncCurrencyExchangeListRetailProvABCSImpl
SyncCurrencyExchangeListRetailProvJMSProducer
Figure 2-2 diagram illustrates the currency exchange rate integration flow.
This sequence diagram is applicable to initial load, create, and update integration flows.
When you initiate the process:
PeopleSoft writes to the AIA_PeopleSoftCurrencyExchangeJMSQueue whenever a currency exchange rate is created or updated.
The CurrencyExchangePeopleSoftJMSConsumer service picks up the message from AIA_PeopleSoftCurrencyExchangeJMSQueue based on MessageName and invokes SyncCurrencyExchangeListPeopleSoftReqABCSImpl with SyncCurrencyExchangeListPSFTABM, and then this thin ReqABCS populates EBMHeader and invokes CurrencyExchangeEBS.
CurrencyExchangeEBS invokes SyncCurrencyExchangeListRetailProvABCSImpl or CAVS based on the routing rule.
The SyncCurrencyExchangeListRetailProvABCSImpl service transforms SyncCurrencyExchangeListEBM into Retail Application Business Message (ABM) and invokes SyncCurrencyExchangeListRetailProvJMSProducer.
The SyncCurrencyExchangeListRetailProvJMSProducer service transforms the CurrencyExchangeRetailABC to a RIBMessage and publishes the RIBMessage to the <username>.ETEXTCURRATE topic in the RIB Queue system.
Note:
The structure of the PeopleSoft ABM is very close to that of an enterprise business message (EBM). PeopleSoft ABM does not have some details, such as the EBM header and the Oracle AIA namespace. These details are added by the PeopleSoft Application Business Connector Service (ABCS). Therefore, the PeopleSoft objects are referred as ABMs even though their content is structured in the EBM schema.
Outbound Interactions
SyncCurrencyExchangeList (Asynchronous)
Request Schema: ExchangeRateSyncEBM.V1.xsd
For more information, see the Enterprise PeopleTools PeopleBook, "PeopleSoft Integration Broker," Managing Service Operations.
Inbound Interactions
SyncCurrencyExchangeList(Asynchronous)
Request Schema: CurrRateDesc.xsd
For more information, see the RIB Integration Guide.
The currency exchange rate integration uses these components:
CurrencyExchangeEBO
CurrencyExchangeEBM
CurrencyExchangeEBS
The core enterprise business object (EBO) and EBM XSD files can be located by EBO within this parent folder: $AIA_HOME/AIAMetaData/AIAComponents/EnterpriseObjectLibrary/Core/EBO/.
The core Enterprise Business Service (EBS) WSDL files can be located by EBO within this parent folder: $AIA_HOME/AIAMetaData/AIAComponents/EnterpriseBusinessServiceLibrary/Core/EBO/.
For detailed documentation of individual EBOs and EBMs, click the AIA Reference Doc link on EBO and EBM detail pages in the Oracle Enterprise Repository.
For more information about using the Oracle Enterprise Repository and configuring it to provide the AIA Reference Doc link, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Configuring and Using Oracle Enterprise Repository as the Oracle AIA SOA Repository."
You can extend EBOs, for instance, to add new data elements. These extensions are protected and remain intact after a patch or an upgrade.
For more information, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Extensibility for Oracle AIA Artifacts," Extending EBOs.
These services are delivered with the process integration for currency exchange rate:
CurrencyExchangePeopleSoftJMSConsumer
SyncCurrencyExchangeListPeopleSoftReqABCSImpl
CurrencyExchangeEBS
SyncCurrencyExchangeListRetailProvABCSImpl
SyncCurrencyExchangeListRetailProvJMSProducer
For more information about using the Oracle Enterprise Repository and configuring it to provide the AIA Reference Doc link, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Configuring and Using Oracle Enterprise Repository as the Oracle AIA SOA Repository."
CurrencyExchangePeopleSoftJMSConsumer is a Mediator service. It has a JMS adapter called SyncCurrencyExchangeListPeopleSoftJMSConsumer. This adapter listens to the AIA_PeopleSoftCurrencyExchangeJMSQueue and picks up the messages for which MessageName is SyncCurrencyExchangeList. The system invokes SyncCurrencyExchangeListPeopleSoftReqABCSImpl with the SyncCurrencyExchangeListPSFTABM.
Figure 2-3 illustrates the relationship of the CurrencyExchangePeopleSoftJMSConsumer with the other services in the integration flow.
The SyncCurrencyExchangeListPeopleSoftReqABCSImpl service is a BPEL process. This service is a thin requester that receives SyncCurrencyExchangeListPSFTABM from SyncCurrencyExchangePeopleSoftConsumer. This message is transformed to SyncCurrencyExchangeListEBM, which populates EBM Header and populates the cross-reference table. No DVM lookups are required for this message because the PeopleSoft system sends all the Oracle AIA Common values. The system sends this SyncCurrencyExchangeListEBM to CurrencyExchangeEBS.
Figure 2-4 illustrates the relationship of the SyncCurrencyExchangeListPeopleSoftReqABCSImpl with the other services in the integration flow.
CurrencyExchangeEBS routes all currency exchange related actions, such as create and update of currency exchange rate as Sync Currency Exchange Rate message to SyncCurrencyExchangeListRetailProvABCSImpl or Composite Application Validation System (CAVS) based on the filter condition and operations. For this particular integration, only the Sync action is available. Updates and creates are done using the Sync action. Oracle Retail determines whether this Sync Currency Exchange Rate message is for a create action or an update action.
Figure 2-5 illustrates the relationship of the CurrencyExchangeEBS with the other services in the integration flow.
For more information about this EBS, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Designing and Developing EBSs" and Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack, "Understanding EBSs."
SyncCurrencyExchangeListRetailProvABCSImpl is a BPEL process. This service receives the SyncCurrencyExchangeListEBM as a request from CurrencyExchangeEBS and transforms it to the Retail ABM.
Figure 2-6 illustrates the relationship of the SyncCurrencyExchangeListRetailProvABCSImpl with the other services in the integration flow.
SyncCurrencyExchangeListRetailProvJMSProducer is a BPEL process. This service is responsible for taking the SyncCurrencyExchangeListRetailABM and transforming it into the RIBMessage format and then putting the message into the <username>.ETEXTCURRATE topic in the RIB Queue system.
This service performs these actions:
Accepts the CurrencyExchangeRetailABM from SyncCurrencyExchangeListRetailProvABCSImpl
Transforms CurrencyExchangeRetailABM into a RIB message
Puts the RIB message into the <username>.ETEXTCURRATE topic in the RIB Queue system.
Figure 2-7 illustrates the relationship of the SyncCurrencyExchangeListRetailProvJMSProducer with the other services in the integration flow.
This section provides an overview of the process integration for initial loading and incremental synchronization of payment terms between PeopleSoft Payables and the Oracle RMS and discusses the following topics:
In the integrated environment, PeopleSoft Enterprise Financials acts as a payable and accounting engine with Oracle RMS for supplier payment, merchandise write-offs, and prepaid adjustments. It eliminates the need for manually reentering reference data from PeopleSoft Payables to Oracle RMS. Benefits to retailers include reducing the labor cost of double entry and providing more accurate and effective payment of invoices, payment adjustments, and accounting records.
PeopleSoft Payables is the source of valid payment terms. Oracle RMS uses payment terms to apply the correct payment terms to a supplier or purchase order and ensures correct timing of payment and application of payment term discounts.
The payment terms integration synchronizes payment terms information from PeopleSoft Payables to Oracle RMS through these integration flows:
Load initial payment term from PeopleSoft Payables to Oracle RMS. Enables the loading of all current effective-dated payment terms from PeopleSoft Payables to Oracle RMS for a new instance (logical or physical) of Oracle RMS.
Incremental creation and updates of current effective dated payment term from PeopleSoft Payables to Oracle RMS. Enables the synchronization of incremental creation and updates of the payment terms from PeopleSoft Payables to Oracle RMS.
For more information about payment terms, see PeopleSoft Enterprise Source to Settle Common Information PeopleBook, "Defining Procurement Options," Defining Payment Terms.
This integration is not a point-to-point integration between PeopleSoft Payables and Oracle RMS. An Oracle AIA layer serves as an intermediate thin layer of application between PeopleSoft Payables and Oracle RMS. As part of the payment term integration, PeopleSoft Payables sends the payment term to the Oracle AIA layer, and the Oracle AIA layer delivers the information to Oracle RMS. The Oracle AIA layer performs message filtering, message transformation, and message routing.
The integration design assumes that:
Oracle Retail can handle only single-tier payment terms.
PeopleSoft Payables supports multiple-tier payment terms for installment payments.
If the PeopleSoft Payables inactivates a payment term and the end date is not before the current system date or vdate in Oracle Retail, then Oracle Retail rejects it.
All Oracle Retail business units have the same set of payment terms.
Only the Sync operation accepts a list (or collection) message.
The Create and Update operations only accept a single message for new rows created or updated in PeopleSoft Payables.
PeopleSoft Payables can have the same payment terms code in different setIDs.
However, Oracle Retail only supports global payment terms. PeopleSoft sends a common value that represents the setID/payment terms code combination. Users should not set up the same payment terms code value under multiple setIDs when using this integration.
For Sync, Create, and Update payment term messages, PeopleSoft sends GUID as the PeopleSoft key for the payment term header and the terms sequence number for payment term lines.
PeopleSoft payment terms have a record in the Oracle Retail language before you run the Sync operation.
The last update to a payment term in the PeopleSoft application should be in the Oracle Retail language so that the translatable fields appear correct in Oracle Retail.
Oracle Retail does not allow users to create and update payment terms in Oracle RMS.
Payment term integration occurs before supplier initial load and manual setup of freight term in Oracle RMS.
The CreatePaymentTermRetailProvABCSImpl, SyncPaymentTermListRetailProvABCSImpl, and UpdatePaymentTermRetailProvABCSImpl assign the Creation Date Time, originating from the PeopleSoft ABCS implementation, to the end_date_Active if the status code from PeopleSoft is I.
Figure 2-8 illustrates the payment term integration flow.
These services are common to Create, Update, and Sync payment term integration flows:
PaymentTermPeopleSoftJMSConsumer
PaymentTermEBS
PayTermService
These services are specific to Sync payment term integration flow:
SyncPaymentTermListPeopleSoftReqABCSImpl
SyncPaymentTermListRetailProvABCSImpl
These services are specific to Create payment term integration flow:
CreatePaymentTermPeopleSoftReqABCSImpl
CreatePaymentTermRetailProvABCSImpl
These services are specific to Update payment term integration flow:
UpdatePaymentTermPeopleSoftReqABCSImpl
UpdatePaymentTermRetailProvABCSImpl
Figure 2-9 illustrates the synchronize payment term sequence flow.
This sequence diagram is applicable for initial load, create, and update integration flows.
When you initiate the process:
PeopleSoft puts the SyncPaymentTermListPSFTABM, CreatePaymentTermPSFTABM, and UpdatePaymentTermPSFTABM in the AIA_PeopleSoftPaymentTermsJMSQueue with MessageName set to SyncPaymentTermList/CreatePaymentTerm/UpdatePaymentTerm.
The PaymentTermPeopleSoftJMSConsumer listens on the AIA_PeopleSoftPaymentTermsJMSQueue and invokes SyncPaymentTermListPeopleSoftReqABCSImpl if SyncPaymentTermListPSFTABM, CreatePaymentTermPeopleSoftReqABCSImpl if CreatePaymentTermPSFTABM, and UpdatePaymentTermPeopleSoftReqABCSImpl if UpdatePaymentTermPSFTABM.
For the initial load, PeopleSoft invokes the SyncPaymentTermListPeopleSoftReqABCSImpl service with SyncPaymentTermListPSFTABM.
This service performs these actions:
Transforms SyncPaymentTermListPSFTABM to SyncPaymentTermListEBM.
Populates EBMHeader.
Updates cross-reference data.
Enriches the message and puts action code for header and lines if it is Create or Update, and invokes PaymentTermEBS.
When you create a new payment term in PeopleSoft, the system invokes CreatePaymentTermPeopleSoftReqABCSImpl with CreatePaymentTermPSFTABM.
This service performs these actions:
Transforms CreatePaymentTermPSFTABM to CreatePaymentTermEBM.
Populates EBMHeader.
Updates cross-reference data.
Invokes PaymentTermEBS.
When you update a payment term in PeopleSoft, the system invokes the UpdatePaymentTermPeopleSoftReqABCSImpl service with UpdatePaymentTermPSFTABM.
This service performs these actions:
Transforms UpdatePaymentTermPSFTABM to UpdatePaymentTermEBM.
Populates EBMHeader.
Enriches the message and puts action code for lines if it is Create or Update and invokes PaymentTermEBS.
PaymentTermEBS invokes SyncPaymentTermListRetailProvABCSImpl, CreatePaymentTermRetailProvABCSImpl, UpdatePaymentTermRetailProvABCSImpl, or CAVS based upon the operation and filter condition.
The SyncPaymentTermRetailProvABCSImpl service transforms SyncPaymentTermListEBM to Retail ABM.
Transformation synchronously invokes create or update PayTermService web service from Oracle RMS.
The CreatePaymentTermRetailProvABCSImpl service transforms CreatePaymentTermEBM to Retail ABM.
Transformation synchronously invokes the create PayTermService web service from Oracle RMS.
The UpdatePaymentTermRetailProvABCSImpl transforms UpdatePaymentTermEBM to Retail ABM.
Transformation synchronously invokes the update PayTermService web service from Oracle RMS.
Note:
The structure of the PeopleSoft ABM is very close to that of an EBM. PeopleSoft ABM does not have some details, such as the EBM header and the Oracle AIA namespace. These details are added by the PeopleSoft ABCS. Therefore, the PeopleSoft objects are referred as ABMs even though they have the content structured in the EBM schema.
Oracle Retail supports multiple languages, however, one language is considered primary.
The PeopleSoft system supports several languages per instance based on user localization preferences. Any translatable data attribute (such as payment term name) may have multiple occurrences, each one representing the language of the user who entered or updated it in the PeopleSoft system. For example, the data field for the payment term name has a French entry from a user with a French UI preference and an English entry from a user with an English UI preference.
Because Oracle Retail supports only one primary language per instance, the Oracle AIA layer filters Oracle Retail records on the provider based on the EBM header language code. The primary language supported by the Oracle Retail instance is identified in AIAConfigurationProperties.XML.
The filtering operation includes a DVM language code lookup based on the common EBM Header. If the DVM language code lookup returns the same value stored in the AIAConfigurationProperties.XML, then the Oracle Retail record on the provider is accepted.
While PeopleSoft Payables can support multiple-tier payment terms, Oracle RMS can support only single-tier payment terms. The Oracle AIA integration for payment terms passes only translatable fields from PeopleSoft to Oracle Retail for the primary language of the Oracle Retail instance being integrated. This condition applies to the incremental creates and updates of payment terms.
For the incremental creates and updates of payment terms, Oracle AIA does not filter the message from PeopleSoft. Oracle AIA sends the message in the same language in which it was created or updated, even if this language is not the primary language of the Oracle Retail instance.
Oracle AIA on the Oracle Retail side filters initial load, create, and update messages and sends only those messages that have the language code similar to the Oracle Retail primary language code.
Outbound Interactions
SyncPaymentTerm (Asynchronous, one-way)
Request Schema: AP_PAY_TERM_SYNC_EBM.V1.xsd
CreatePaymentTerm (Asynchronous, one-way)
Request Schema: AP_CREATE_PAY_TERM_SYNC_EBM.V1.xsd
UpdatePaymentTerm (Asynchronous, one-way)
Request Schema: AP_UPDATE_PAY_TERM_SYNC_EBM.V1.xsd
Inbound Interactions
PayTermService
Operation: CreatePayTermDesc, Request Schema: PayTermDesc.xsd, Response Schema: PayTermRef.xsd
Operation: UpdatePayTermDesc, Request Schema: PayTermDesc.xsd, Response Schema: PayTermRef.xsd
Operation: CreateDetailPayTermDesc, Request Schema: PayTermDesc.xsd, Response Schema: PayTermRef.xsd
Operation: UpdateHeaderPayTermDesc, Request Schema: PayTermDesc.xsd, Response Schema: PayTermRef.xsd
For more information, see the RMS Operations Guide, "Web Services Overview."
The Payment term integration uses these components:
PaymentTermEBO
PaymentTermEBS
PaymentTermEBM
The core EBO and EBM XSD files can be located by EBO within this parent folder: $AIA_HOME/AIAMetaData/AIAComponents/EnterpriseObjectLibrary/Core/EBO/.
The core EBS WSDL files can be located by EBO within this parent folder: $AIA_HOME/AIAMetaData/AIAComponents/EnterpriseBusinessServiceLibrary/Core/EBO/.
For detailed documentation about individual EBOs and EBMs, click the AIA Reference Doc link on EBO and EBM detail pages in the Oracle Enterprise Repository.
For more information about using the Oracle Enterprise Repository and configuring it to provide the AIA Reference Doc link, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Configuring and Using Oracle Enterprise Repository as the Oracle AIA SOA Repository."
EBOs can be extended, for instance, to add new data elements. These extensions are protected, and remain intact after a patch or an upgrade.
For more information, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Extensibility for AIA Artifacts," Extending EBOs.
These services are delivered with the process integration for payment term:
PaymentTermPeopleSoftJMSConsumer
SyncPaymentTermListPeopleSoftReqABCSImpl
CreatePaymentTermPeopleSoftReqABCSImpl
UpdatePaymentTermPeopleSoftReqABCSImpl
PaymentTermEBS
SyncPaymentTermListRetailProvABCSImpl
CreatePaymentTermRetailProvABCSImpl
UpdatePaymentTermRetailProvABCSImpl
PayTermService
For more information about using the Oracle Enterprise Repository and configuring it to provide the AIA Reference Doc link, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Configuring and Using Oracle Enterprise Repository as the Oracle AIA SOA Repository."
This service is a Mediator process. It has three different JMS adapters: SyncPaymentTermListPeopleSoftJMSConsumer, CreatePaymentTermPeopleSoftJMSConsumer, and UpdatePaymentTermPeopleSoftJMSConsumer. Each of these adapters listens to the AIA_PeopleSoftPaymentTermsJMSQueue. When a message is found in the JMS queue, based on MessageName, one of three adapters picks up the message and invokes SyncPaymentTermListPeopleSoftReqABCSImpl, CreatePaymentTermPeopleSoftReqABCSImpl, or UpdatePaymentTermPeopleSoftReqABCSImpl, respectively.
Figure 2-10 illustrates the relationship of the PaymentTermPeopleSoftJMSConsumer with the other services in the integration flow.
SyncPaymentTermListPeopleSoftReqABCSImpl is a thin requester that receives SyncPaymentTermListPSFTABM from PeopleSoft primarily for synchronizing the initial loads. This is a single operation service that has PaymentTermEBS as a partner service. It transforms the input to SyncPaymentTermListEBM, which is primarily for populating the EBM Header, populating the cross-reference, and setting the environment code to CAVS or PRODUCTION based on the RouteToCAVS property in the AIAConfigurationProperties file. The Request message adheres to the SyncPaymentTermListEBM XML Schema element.
This service is a BPEL process.
Partner Link Service: The SyncPaymentTermPeopleSoftReqABCSImplExt is an extensibility service that enables customers to filter, validate, or augment the input. This service accepts SyncPaymentTermListEBM as input and returns the same.
Figure 2-11 illustrates the relationship of the SyncPaymentTermListPeopleSoftReqABCSImpl with the other services in the integration flow.
CreatePaymentTermPeopleSoftReqABCSImpl is a thin requester that receives CreatePaymentTermPSFTABM from PeopleSoft. This input is transformed to CreatePaymentTermEBM. It populates EBM Header cross-reference data population and sends this EBM to PaymentTermEBS.
This is a single operation service that has PaymentTermEBS as a partner service. This service is a BPEL process.
Partner Link Service: The CreatePaymentTermPeopleSoftReqABCSImplExtension is an extensibility service that enables customers to filter, validate, or augment the input. This service accepts CreatePaymentTermEBM as input and returns the same.
Figure 2-12 illustrates the relationship of the CreatePaymentTermPeopleSoftReqABCSImpl with the other services in the integration flow.
UpdatePaymentTermPeopleSoftReqABCSImpl is a thin requester that receives UpdatePaymentTermPSFTABM from PeopleSoft. It transforms the input to UpdatePaymentTermEBM. It also populates EBM Header and sends this EBM to PaymentTermEBS. This is a single operation service, which has PaymentTermEBS as a partner service.
Partner Link Service: The UpdatePaymentTermPeopleSoftReqABCSImplExt is an extensibility service that enables customers to filter, validate, or augment the input. This service accepts UpdatePaymentTermEBM as input and returns the same.
Figure 2-13 illustrates the relationship of the UpdatePaymentTermPeopleSoftReqABCSImpl with the other services in the integration flow.
PaymentTermEBS is a Mediator service. It routes to SyncPaymentTermListRetailProvABCSImpl, CreatePaymentTermRetailProvABCSImpl, UpdatePaymentTermRetailProvABCSImpl, or CAVS based on the operation and filter condition.
Figure 2-14 illustrates the relationship of the PaymentTermEBS with the other services in the integration flow.
For more information about this EBS, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Designing and Developing EBSs" and Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack, "Understanding EBSs."
SyncPaymentTermListRetailProvABCSImpl is a BPEL process. This service accepts a SyncPaymentTermListEBM message as input from PaymentTermEBS. It transforms the input to PaymentTermABM and invokes the web service PayTermService.
This SyncPaymentTermEBM undergoes one of four transformations that transform the input to four types of messages that Oracle Retail accepts, based on the header and detail (line) action code. While transforming the data, the DVM looks up the common EBM language and common status codes to determine the RMS values.
Table 2-1 lists the operations used by this service and related messages.
Table 2-1 Operations Used by SyncPaymentTermListRetailProvABCSImpl
|
Operation |
Input Message |
Output Message |
|
CreatePayTermDesc |
PayTermDesc |
PayTermRef |
|
UpdateHeaderPayTermDesc |
PayTermDesc |
PayTermRef |
|
CreateDetailPayTermDesc |
PayTermDesc |
PayTermRef |
|
UpdatePayTermDesc |
PayTermDesc |
PayTermRef |
The response message from Retail PayTermService for the operation corresponding to PayTermDtlCre message has the terms-seq, which you should use to populate the RETL column in the cross-reference table PAYMENTTERMLINE_ID.
Table 2-1 illustrates the relationship of the SyncPaymentTermListRetailProvABCSImpl with the other services in the integration flow.
CreatePaymentTermRetailProvABCSImpl is a BPEL process. It accepts CreatePaymentTermEBM as input from PaymentTermEBS. It then sends this PaymentTermABM to the PreProcessABM operation of CreatePaymentTermRetailProvABCSImplExt if a service property is set to true in the AIAConfigurationProperties file. This extension service returns the same CreatePaymentTermEBM after processing it, and then transforms it into a PayTermCre message type PaymentTermABM. The PayTermService operation CreatePayTermDesc is invoked with this PaymentTermABM.
The response message from Retail PayTermService, for the operation corresponding to PayTermDtlCre message, has the terms-seq, which you should use to populate the RETL column in the cross-reference table PAYMENTTERMLINE_ID. While transforming the data, the DVM looks up the common status code to determine the RMS-enabled flag value.
Table 2-1 illustrates the relationship of the CreatePaymentTermRetailProvABCSImpl with the other services in the integration flow.
UpdatePaymentTermRetailProvABCSImpl is a BPEL process. It accepts UpdatePaymentTermEBM as input from PaymentTermEBS. This EBM invokes the PreProcessEBM operation of UpdatePaymentTermRetailProvABCSImplExt if a service property in the AIAConfigurationProperties file is set to true. This extension service returns the same UpdatePaymentTermEBM after processing it.
This UpdatePaymentTermEBM undergoes one of three transformations that transform the input to PayTermMod (updateHeaderPayTermDesc), PayTermDtlMod (updatePayTermDesc), or PayTermDtlCre (createDetailPayTermDesc) message type PaymentTermEBS.
After dynamically assigning the partner link based on the RouteToCAVS property in the AIAConfig file, it invokes the Retail PayTermService web service or CAVS. The corresponding operation of the PayTermService is invoked with the corresponding message type Retail ABMs if the RouteToCAVS property is set to false.
The response message from Retail PayTermService for an operation corresponding to the PayTermDtlCre message has the terms-seq, which you should use to populate the RETL column in the cross-reference table PAYMENTTERMLINE_ID.
Table 2-1 illustrates the relationship of the UpdatePaymentTermRetailProvABCSImpl with the other services in the integration flow.
PayTermService accepts PaymentTermABM message types for operations createPayTermDesc, updateHeaderPayTermDesc, updatePayTermDesc, and createDetailPayTermDesc from SyncPaymentTermListRetailProvABCSImpl (for synchronization of a bulk of updated payment terms data) or UpdatePaymentTermRetailProvABCSImpl (for an update of an old payment term). This web service is called synchronously and returns the Retail ID for cross-reference. The PayTermService cannot accept collections, so the messages are split before being sent. While transforming the data, the DVM looks up the common status code to determine the RMS-enabled flag value.
Table 2-1 illustrates the relationship of the PayTermService with the other services in the integration flow.
This section provides an overview of the process integration for initial loading and incremental synchronization of suppliers' information between PeopleSoft Payables and Oracle RMS and discusses the following topics:
In the integrated environment, PeopleSoft Payables acts as a payable and accounting engine, and Oracle RMS handles supplier payments, merchandise write-offs, and prepaid adjustments.
Merchandise suppliers supply goods and services that a retailer sells to customers. PeopleSoft Payables and Oracle RMS must share suppliers' information. Oracle RMS requires the supplier information for several key functions, including creation and management of items and purchase orders. PeopleSoft Payables requires the supplier information for supplier payment. For end-to-end business integration, the two systems must share the same supplier instance and related information.
PeopleSoft Payables is the source of valid suppliers (vendors in PeopleSoft Payables) and their Remit to Location and Order from addresses, and the relationships between this supplier data and the financial business unit structure.
The supplier integration synchronizes supplier information from PeopleSoft Payables to Oracle RMS through these integration flows:
Load Initial Suppliers from PeopleSoft Payables to Oracle RMS. Enables the loading of all active merchandise suppliers, the current effective supplier locations and their current effective remit and order-to addresses, and the relationship between the supplier data and the financial business unit structure from PeopleSoft Payables to Oracle RMS for a new instance (logical or physical) of Oracle RMS. It is a pre-implementation stage. PeopleSoft suppliers must be classified as supplier and have the open for ordering attribute for the initial load.
Incremental Creation and Updates of Suppliers from PeopleSoft Payables to Oracle RMS. Enables the synchronization of incremental creation and updates of the current effective-dated suppliers from PeopleSoft Payables to Oracle RMS.
For more information about supplier create and update operations, see PeopleSoft Enterprise Source to Settle Common Information PeopleBook, "Maintaining Vendor Information."
This integration is not a point-to-point integration between PeopleSoft Payables and Oracle RMS. An Oracle AIA layer serves as an intermediate thin layer of application between PeopleSoft Payables and Oracle RMS. As part of the supplier integration, PeopleSoft Payables sends supplier information to the Oracle AIA layer, and the Oracle AIA layer delivers the information to Oracle RMS. The Oracle AIA layer performs message filtering, message transformation, and message routing. Because this integration is point-to-point, the vendor number (ID) in PeopleSoft is not similar to the supplier number (ID) in Oracle Retail.
The integration design assumes that:
PeopleSoft Payables is the source system for merchandise suppliers, their contacts, locations, addresses, and business unit structure.
You can create suppliers and suppliers' locations in PeopleSoft Payables.
You can maintain the relationship between suppliers, suppliers' locations, and financial structure in PeopleSoft Payables. This integration is a one-way synchronization. Any update to supplier information in Oracle RMS is not synchronized with PeopleSoft Payables.
The volume of payload (SupplierPartyList) that the process handles depends on the server configuration.
PeopleSoft sends the suppliers in batches based on different criteria.
PeopleSoft Payables sends all current effective addresses in the message.
This message contains, for each trading location, specific and detailed Order from and Remit to addresses.
The PeopleSoft system sends all related information to Oracle AIA.
For example, if an address changes, then all the current effective locations with that address and all the suppliers linked to that location are included in the message. The same is true for the reverse: if supplier information changes, then all its locations and addresses are sent.
The PeopleSoft system sends the COMMON field for the DVM lookup.
DVM lookup in the PeopleSoft ABCS is unnecessary because the DVM lookup is done only in the Oracle RMS side Provider ABCS.
PeopleSoft suppliers have a record in the Oracle Retail language before the performance of the sync operation.
The last update to a supplier in the PeopleSoft application should be in the Oracle Retail primary language, so that the translatable fields appear correct in Oracle Retail.
PeopleSoft Payables sends supplier information for approved, unapproved, inactive, and archived suppliers.
The Oracle AIA layer for the Retail side filters and allows only approved and inactive suppliers during the create operation. If a supplier is active but not open for ordering, the Oracle AIA layer changes its status to inactive. For the update operation, the Oracle AIA layer allows only approved suppliers.
These are the constraints for the suppliers' integration:
The Oracle AIA services do not know the changes in the supplier unless PeopleSoft Payables notifies them.
The Oracle AIA integration solutions do not correct failure in the processing of messages in Oracle RMS. Oracle AIA only sends a fault message.
PeopleSoft Payables does not automatically send the same message again. In some cases, if a message fails on the PeopleSoft side, you use a manual process to resubmit the message.
PIP is responsible only for invoking the Oracle RMS web service.
Table 2-1 illustrates the supplier integration flow.
These services are common to Create, Update, and Sync supplier integration flows:
SupplierPartyPeopleSoftJMSConsumer
SupplierPartyEBS
These services are specific to Sync supplier integration flows:
SyncSupplierPartyListPeopleSoftReqABCSImpl
SyncSupplierPartyListRetailProvABCSImpl
These services are specific to Create supplier integration flows:
CreateSupplierPartyPeopleSoftReqABCSImpl
CreateSupplierPartyRetailProvABCSImpl
These services are specific to Update supplier integration flows.
UpdateSupplierPartyRetailProvABCSImpl
UpdateSupplierPartyPeopleSoftReqABCSImpl
Table 2-1 illustrates the supplier information integration flow.
This sequence diagram is applicable to initial load, create, and update integration flows.
When you initiate the process:
PeopleSoft Payables puts the SyncSupplierPartyListPSFTABM, CreateSupplierPartyPSFTABM, and UpdateSupplierPartyPSFTABM in the AIA_PeopleSoftSupplierPartyJMSQueue with MessageName set to SyncSupplierPartyList/CreateSupplierParty/UpdateSupplierParty.
The SupplierPartyPeopleSoftJMSConsumer service listens on the AIA_PeopleSoftSupplierPartyJMSQueue and invokes SyncSupplierPartyListPeopleSoftReqABCSImpl for SyncSupplierPartyListPSFTABM, CreateSupplierPartyPeopleSoftReqABCSImpl for CreateSupplierPartyPSFTABM and UpdateSupplierPartyPeopleSoftReqABCSImpl for UpdateSupplierPartyPSFTABM.
The SyncSupplierPartyListPeopleSoftReqABCSImpl transforms the SupplierPartyListABM message into SupplierPartyListEBM.
Transformation does cross-referencing for system-specific values and calls the SupplierPartyEBS with operation SyncSupplierPartList. SupplierPartyEBS is a Mediator service with several operations on the supplier EBO.
The CreateSupplierPartyPeopleSoftReqABCSImpl transforms the SupplierPartyABM message into SupplierPartyEBM.
Transformation does cross-referencing for system-specific values and calls the SupplierPartyEBS with operation CreateSupplierParty. SupplierPartyEBS is a Mediator service with several operations on the supplier EBO.
The UpdateSupplierPartyPeopleSoftReqABCSImpl transforms the SupplierPartyABM message into SupplierPartyEBM.
Transformation does cross-referencing for system-specific values and calls the SupplierPartyEBS with operation UpdateSupplierParty. SupplierPartyEBS is a Mediator service with several operations on the supplier EBO.
SupplierPartyEBS routes the SupplierPartyListEBM to Retail provider ABCS implementation. It also provides CAVS routing.
SyncSupplierPartyListRetailProvABCSImpl transforms SupplierPartyListEBM to Retail supplier message ABM.
Transformation applies the DVM and invokes create or update web service from Oracle RMS. It also updates the cross-reference table after the Retail web service call.
CreateSupplierPartyRetailProvABCSImpl transforms SupplierPartyEBM to Retail supplier message ABM.
Transformation applies the DVM and invokes a create web service from Oracle RMS. It also updates the cross-reference table after the Retail web service call.
UpdateSupplierPartyRetailProvABCSImpl transforms SupplierPartyEBM to Retail supplier message ABM.
Transformation applies the DVM and invokes an update web service from Oracle RMS. It also updates the cross-reference table after the Retail web service call.
Note:
The structure of the PeopleSoft ABM is very close to that of an EBM. PeopleSoft ABM does not have some details, such as the EBM header and the Oracle AIA namespace. These details are added by the PeopleSoft ABCS. So the PeopleSoft objects are referred as ABMs even though they have the content structured in the EBM schema.
Oracle Retail supports multiple languages, however, one language is considered primary.
The PeopleSoft system supports several languages per instance based on user localization preferences. Any translatable data attribute (such as supplier name) may possibly have multiple occurrences, each one representing the language of the user who entered or updated it in the PeopleSoft system. For example, the data field for the supplier name has a French entry from a user with a French UI preference and an English entry from a user with an English UI preference.
Because Oracle Retail supports only one primary language per instance, the Oracle AIA layer filters Oracle Retail records on the provider based on the EBM header language code. The primary language supported by the Oracle Retail instance is identified in AIAConfigurationProperties.XML.
The filtering operation includes a DVM language code lookup based on the common EBM Header. If the DVM language code lookup returns the same value stored in the AIAConfigurationProperties.XML, then the Oracle Retail record on the provider is accepted.
For the incremental creates and updates of a supplier, Oracle AIA does not filter the message from PeopleSoft. Oracle AIA sends the message in the same language in which it was created or updated, even if this language is not the primary language of the Oracle Retail instance.
Oracle AIA on the Retail side filters initial load, create, and update messages and sends only those messages that have a language code similar to the Oracle Retail primary language code.
Outbound Interactions
Sync SupplierParty (Asynchronous, one-way)
Request Schema: AP_VENDOR_SYNC_EBM.V1.xsd
Create SupplierParty (Asynchronous, one-way)
Request Schema: AP_CREATE_VENDOR_SYNC_EBM.V1.xsd
Update SupplierParty (Asynchronous, one-way)
Request Schema: AP_UPDATE_VENDOR_SYNC_EBM.V1.xsd
Inbound Interactions
SupplierServicePortFactory
Operation: createSupplierCollectionDesc, Request Schema: SupplierCollectionDesc.xsd, Response Schema: SupplierCollectionRef.xsd
Operation: updateSupplierCollectionDesc, Request Schema: SupplierCollectionDesc.xsd, Response Schema: SupplierCollectionRef.xsd
Operation: createSupplierDesc, Request Schema: SupplierDesc.xsd, Response Schema: SupplierRef.xsd
Operation: updateSupplierDesc, Request Schema: SupplierDesc.xsd, Response Schema: SupplierRef.xsd
For more information, see the RMS Operations Guide, "Web Services Overview."
The supplier Information integration uses these components:
Merchandise Supplier EBO (SupplierPartyEBO)
Merchandise Supplier EBS (SupplierPartyEBS)
Merchandise Supplier EBM (SupplierPartyEBM)
The core EBO and EBM XSD files can be located by EBO within this parent folder: $AIA_HOME/AIAMetaData/AIAComponents/EnterpriseObjectLibrary/Core/EBO/.
The core EBS WSDL files can be located by EBO within this parent folder: $AIA_HOME/AIAMetaData/AIAComponents/EnterpriseBusinessServiceLibrary/Core/EBO/.
For detailed documentation about individual EBOs and EBMs, click the AIA Reference Doc link on EBO and EBM detail pages in Oracle Enterprise Repository.
For more information about using the Oracle Enterprise Repository and configuring it to provide the AIA Reference Doc link, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Configuring and Using Oracle Enterprise Repository as the Oracle AIA SOA Repository."
EBOs can be extended, for instance, to add new data elements. These extensions are protected and remain intact after a patch or an upgrade.
For more information, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Extensibility for Oracle AIA Artifacts," Extending EBOs.
These services are delivered with the process integration for supplier information:
SupplierPartyPeopleSoftJMSConsumer
SyncSupplierPartyListPeopleSoftReqABCSImpl
CreateSupplierPartyPeopleSoftReqABCSImpl
UpdateSupplierPartyPeopleSoftReqABCSImpl
SupplierPartyEBS
SyncSupplierPartyListRetailProvABCSImpl
CreateSupplierPartyRetailProvABCSImpl
UpdateSupplierPartyRetailProvABCSImpl.
For more information, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Configuring and Using Oracle Enterprise Repository as the Oracle AIA SOA Repository."
SupplierPartyPeopleSoftJMSConsumer is a Mediator service. It has three JMSAdapter services for dequeue of the message from the queue. After dequeing the messages, it calls for the respective PeopleSoftReqABCSImpl (Create, Update, or Sync).
This service has these JMS adapters:
SyncSupplierPartyPeopleSoftJMSConsumer
CreateSupplierPartyPeopleSoftJMSConsumer
UpdateSupplierPartyPeopleSoftJMSConsumer
Table 2-1 illustrates the relationship of the SupplierPartyPeopleSoftJMSConsumer with the other services in the integration flow.
SupplierPartyPeopleSoftJMSConsumer invokes the SyncSupplierPartyListPeopleSoftReqABCSImpl service for the list of existing suppliers during the initial integration with other applications.
This service is a single operation service that has SupplierPartyEBS as a partner service. It accepts a PeopleSoft SupplierPartyListEBM message as a request and does not return a response to the calling service. This service is a BPEL process.
This service performs these actions:
Accepts a SyncSupplierPartyListReqMsg message from PeopleSoft. This message contains a cross-reference for suppliers and suppliers' addresses.
Transforms SyncSupplierPartyListReqMsg to SyncSupplierPartyListEBM. While it is transforming ABM to EBM, it looks up cross-references for SUPPLIERPARTY_ID, SUPPLIERPARTY_LOCATION_ID, and SUPPLIERPARTY_ADDRESS_ID.
Sends SyncSupplierPartyListEBM messages as input to the SyncSupplierPartyList operation in the SupplierPartyEBS service.
Table 2-1 illustrates the relationship of the SyncSupplierPartyListPeopleSoftReqABCSImpl with the other services in the integration flow.
This service is a single operation service that has SupplierPartyEBS as a partner service. This service is invoked by SupplierPartyPeopleSoftJMSConsumer as a part of the new supplier information synchronization. This service is a BPEL process.
This service performs these actions:
Accepts a CreateSupplierPartyReqMsg as a request and does not return a response to the calling service.
This message contains a cross-reference for suppliers and suppliers' addresses.
Transforms CreateSupplierPartyReqMsg to CreateSupplierPartyEBM.
While it is transforming ABM to EBM, it looks up cross-references for SUPPLIERPARTY_ID, SUPPLIERPARTY_LOCATION_ID, and SUPPLIERPARTY_ADDRESS_ID.
Sends the CreateSupplierPartyEBM message as an input to the CreateSupplierParty operation in the SupplierPartyEBS service.
Table 2-1 illustrates the relationship of the CreateSupplierPartyPeopleSoftReqABCSImpl with the other services in the integration flow.
This service is a single operation service that has SupplierPartyEBS as a partner service. It accepts a PSFT supplier message as a request and does not return a response to the calling service. This service is a BPEL process triggered by SupplierPartyPeopleSoftJMSConsumer.
The process performs these actions:
Accepts the UpdateSupplierPartyReqMsg message from PeopleSoft Payables.
This message contains a cross-reference for suppliers and suppliers' addresses.
Transforms UpdateSupplierPartyReqMsg to UpdateSupplierPartyEBM.
While it is transforming ABM to EBM, it looks up a cross-reference for SUPPLIERPARTY_ID, SUPPLIERPARTY_LOCATION_ID, and SUPPLIERPARTY_ADDRESS_ID.
Sends the UpdateSupplierPartyEBM message as an input to the UpdateSupplierParty operation in the SupplierPartyEBS service.
Table 2-1 illustrates the relationship of the UpdateSupplierPartyPeopleSoftReqABCSImpl with the other services in the integration flow.
SupplierPartyEBS performs all supplier-related actions, such as Create Supplier, Update Supplier, and Sync Supplier. It routes incoming Sync, Update, or Create messages to the respective ProviderABCSImpl. No transformation is done in this EBS.
Table 2-1 illustrates the relationship of the SupplierPartyEBS with the other services in the integration flow.
These operations on the SupplierPartyEBS are used in the supplier information integration flow:
SyncSupplierPartyList
CreateSupplierParty
UpdateSupplierParty
For more information about this EBS, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack, "Designing and Developing EBSs" and Oracle Fusion Middleware Concepts and Technologies Guide for Oracle Application Integration Architecture Foundation Pack, "Understanding EBSs."
SyncSupplierPartyListRetailProvABCSImpl is a single operation service. This service is a BPEL process.
This process performs these actions:
Receives input from SupplierPartyEBS.
Accepts a SyncSupplierPartyListEBM message. A SyncSupplierPartyListEBM message contains these details:
Standard supplier attributes
Supplier contacts information
Supplier location information
Supplier location contact information
Supplier location remit address information
Supplier location remit address contact information
Supplier location order address information
Supplier location order address contact information
Supplier location business unit
Transforms SyncSupplierPartyListEBM into a SyncSupplierRetailABM message.
During transformation, the DVM lookups change the value for language code, state, country code, currency code, SupplierParty address type, and SupplierParty status code.
Invokes the Create/UpdateSupplierPartyList WSDL after transforming the message from the SyncSupplierEBS to SyncSupplierPartyList ABM and wrapping the ABM in WSDL.
Updates the cross-references for Oracle Retail after the Oracle Retail web service call.
Table 2-1 illustrates the relationship of the SyncSupplierPartyListRetailProvABCSImpl with the other services in the integration flow.
CreateSupplierPartyRetailProvABCSImpl is a single operation service. It is a BPEL process.
This process performs these actions:
Receives input from SupplierPartyEBS.
Invokes the RMS web service after transforming the message from the SupplierPartyEBS to CreateSupplierParty ABM and wrapping the ABM in a WSDL message.
Accepts a CreateSupplierPartyEBM message. A CreateSupplierPartyEBM message contains these details:
Standard supplier attributes
Supplier contacts information
Supplier location information
Supplier location contact information
Supplier location remit address information
Supplier location remit address contact information
Supplier location order address information
Supplier location order address contact information
Supplier location business unit
Transform CreateSupplierPartyEBM into a CreateSupplierRetailABM message.
During transformation, the DVM lookups change the value for language code, state, country code, currency code, SupplierParty address type, and SupplierParty status code. After CreateSupplierRetailABM message construction, the Oracle RMS web service is invoked for create.
Updates the cross-references for Oracle Retail after the Oracle Retail web service call.
Table 2-1 illustrates the relationship of the CreateSupplierPartyRetailProvABCSImpl with the other services in the integration flow.
UpdateSupplierPartyRetailProvABCSImpl is a single operation service that receives input from SupplierPartyEBS. It invokes the Update web service in Oracle RMS after transforming the message from the SupplierPartyEBS to UpdateSupplierParty ABM and wrapping the ABM in a WSDL message. It is a BPEL process.
The process performs these actions:
Accepts an UpdateSupplierPartyEBM message.
An UpdateSupplierPartyEBM message contains these details:
Standard supplier attributes
Supplier contacts information
Supplier location information
Supplier location contact information
Supplier location remit address information
Supplier location remit address contact information
Supplier location order address information
Supplier location order address contact information
Supplier location business unit
Transforms UpdateSupplierPartyEBM into UpdateSupplierRetailABM.
During transformation, the DVM lookups change the value for language code, state, country code, currency code, SupplierParty address type, and SupplierParty status code.
Updates the cross-references for Oracle Retail after the Oracle Retail web service call.
Table 2-1 illustrates the relationship of the UpdateSupplierPartyRetailProvABCSImpl with the other services in the integration flow.
|
 Copyright © 2001, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
