| Oracle® Application Integration Architecture Oracle Product Master Data Management Integration Implementation Guide Release 11.1 Part Number E22578-04 |
|
|
PDF · Mobi · ePub |
| Oracle® Application Integration Architecture Oracle Product Master Data Management Integration Implementation Guide Release 11.1 Part Number E22578-04 |
|
|
PDF · Mobi · ePub |
The Oracle Product Hub (OPH) provides single, blended records through consolidation, cleansing, and governance of product information and publishes the enriched, cleansed data to the systems that need this information for individual, application-specific functionality.
For more information about the concepts and terms related to Oracle Product Hub, see Oracle Product Hub Implementation Guide documentation.
This chapter includes the following sections:
The following features are supported by the base pack. These are implemented as end-end process flows for various applications in the Product MDM integration.
Synchronization of Metadata.
Synchronization of Item Catalog Categories:
Synchronization of Relationships/Structure under Item Catalog Categories.
Synchronization of Attribute Groups as part of Item Catalog Categories.
Synchronization of Customer UDA as part of Item Catalog Categories.
Synchronization of Transaction attributes as part of Item Catalog Categories.
Synchronization of Item Catalog Category Hierarchies.
Synchronization of Valuesets:
Synchronization of Valuesets as part of Item Catalog Categories.
Synchronization of Valuesets Independently.
Multi Language Support for Valuesets.
Options Supported
Siebel integration option: Since these are implemented as end-end process flows, see Chapter 3, "Oracle Product Master Data Management Integration Option for Siebel CRM" for functional and technical explanations of the features.
Synchronization of Items and BOMs
Options supported:
Oracle E-Business Suite Option: these flows are implemented as end-to-end process flows. For functional and technical explanations of the features, see Chapter 4, "Oracle Product Master Data Management Integration Option for Oracle E-Business Suite".
Siebel Option: these flows are implemented as end-to-end process flows. For functional and technical explanations of the features, see Chapter 3, "Oracle Product Master Data Management Integration Option for Siebel CRM".
BRM Option: these flows are implemented as end-to-end process flows. For functional and technical explanations of the features, see Chapter 5, "Oracle Product Master Data Management Integration Option for Oracle Communications BRM".
These features are supported by all of the process flows for all of the integration options:
Support for routing driven through explicit specification of target systems.
Support for multi-language for item synchronization.
Support for telecommunications seeded library attributes.
Support for updating publishing status in OPH upon publication of items.
For more information about the features applicable to an integration option, see the chapter for that integration option.
The synchronization of items and BOMs is used by all of the integration options supported by the Product MDM integration.
This synchronization enables definition of products, discounts, and promotions as items in the Oracle Product Hub and publishes these to one or more Siebel CRM instances to be used by the order capture process as well as other processes. It enables you to organize simple products into structures and to select the desired structure to publish along with products and promotions.
The synchronization reduces manual effort in keeping definitions of product, discounts, promotions, and other entities aligned across multiple CRM systems and ensures that a common set of products is accurately represented and available across all systems to facilitate transactional processes such as order capture, order fulfillment, and so on.
The synchronization service is triggered by the publication of a synchronize item event by Oracle Product Hub, which contains this information:
BATCH_ID
STRUCTURE_FLAG
Workspace Name
Auto-Release
Upon receiving the publishing event, the requestor ABCS queries from OPH the list of target systems to which the batch has to be published. See Section 2.3.1, "Support for Routing Driven Through Explicit Specification of Target Systems".
At the batch level, a list of target systems is captured to identify the systems that should receive the list of items payload. This list of target systems is used for routing the list of items payload to the consuming applications. This list of target systems is queried by the requestor after the publishing event is received.
If only the items need to be published, then the STRUCTURE_FLAG is N. If a structure is published, STRUCTURE_FLAG is Y and the list of items payload contains the data for both the root items and the other items in the published structures.
Complete information is always published for each item in the list of items payload. The receiving applications are expected to perform a synchronization of the received entity. For each entity, the fields that are passed in with a value are updated with the provided value. Those passed in with NULL or empty values are nullified. The fields that are not passed in are left as is.
Complete information is always published for each item in the list of items payload. The receiving applications are expected to perform a synchronization of the received entity. For each entity, the fields that are passed in with a value are updated with the provided value. Those passed in with NULL or empty values are nullified. The fields that are not passed in are left as is.
Within the published payload, some of the items may not apply to some of the target systems, for example, promotions to Oracle BRM. For each item, the list of items payload also contains a multivalue attribute that is used to identify the destination systems for the items (implemented in OPH as a multi-row UDA); this attribute identifies the systems that should process the specific item within the batch. The destination systems attribute is used by filtering rules for a given target system; these filtering rules are used to identify the payload entities pertinent to the specific target system.
Various types of items are published by OPH. OPH uses the UDA Entity type to capture the type of the item. Possible values are:
Product
Discounts
Discount Model (this is not published)
Promotion
Option Group
Bundle
OPH provides a service with an operation that, given the batch ID published in the item publishing event, returns the payload for containing all the items published in that batch. The integration uses this service to retrieve the application payload for the items that need to be published. This service has another operation by which it takes the batch ID published in the item-publishing event and returns a payload with a list of all the BOMs (structures) published in the batch; however, if the structure flag is N, it does not retrieve the list of BOMs payload.
The payload for the list of items and list of BOMs is the complete payload containing all attributes and entities even when the publishing takes place to update existing entities.
The list of BOMs payload contains the structures associated with the root items. The type of structure (for example, sales BOM, manufacturing BOM, marketing BOM, support BOM, and so on) is the same for all the BOMs in the payload as it was defined by the header-level attribute structure name. No multi-row, UDA destination systems are associated directly with BOMs. All BOMs go to all providers that consume BOMs. The DVM setting defines whether a provider consumes or does not consume BOMs. For a given target system, the synchronization of BOMs does not take place if the synchronization of items fails.
OPH-published messages can be generated from any number of organizations that have been established. The integration solution is based on manual pre-synchronization of organizations between OPH, Siebel, and EBS and creation of appropriate cross-references. The organization used for publication in OPH is submitted and mapped to the corresponding organization in the target application, if any.
For more information, see Section 6.4, "Setting Up Cross-References".
Figure 2-1 shows the process flow from Oracle Product Hub to the participating applications (integration options) for item and BOM synchronization:
Figure 2-1 Synchronization of items and BOMs from OPH to Oracle BRM, Siebel CRM and Oracle E-Business Suite
The business process flow is as follows:
Oracle Product Hub publishes an item publish event to application integration architecture (AIA).
The event consumer within the OPH application business connector service (ABCS) (requestor) receives and processes the event. The event contains the batch ID, which is used to query data from OPH.
The OPH requestor ABCS queries the list of target systems from OPH based on the batch ID.
The OPH requestor ABCS queries the list of items from OPH based on the batch ID.
The requestor ABCS prepares an enterprise business message (EBM) to be sent to each target system. The EBS filters based on the destination system.
For each target system, the requestor ABCS invokes ItemEBS, which filters the items in the EBM based on the destination system user defined attributes (UDA) and routes the processing request to the appropriate provider. This is done sequentially for one provider after the other as described here:
Siebel CRM Provider ABCS
Receives the ItemList EBM and separates items into products and promotions based on the UDA entity type. Items with entity type as product or entity type as discount are processed as products, and items with entity type as promotion are processed as promotions. Two application business messages (ABM) are produced, one for Siebel products, and one for Siebel promotions.
Invokes separate web services on the application to synchronize the products, promotions, and price list.
Prepares the response with the publishing status for the individual items, which is sent back to the requestor ABCS.
Oracle E-Business Suite Provider ABCS
Receives the ItemList EBM and produces one ABM for Oracle E-Business Suite items.
Invokes a web service on the application to synchronize the items.
Prepares the response with the publishing status for the batch, which is sent back to the requestor ABCS.
Oracle BRM Provider ABCS
Receives the ItemList EBM and produces one ABM containing both items for which the entity type is product and for which the entity type is discount.
Invokes a web service on the application to synchronize the discounts and the products. The same web service is also invoked when the product is updated with the pricing information from the price list.
Prepares the response with the publishing status for the individual items, which is sent back to the requestor ABCS.
The requestor ABCS receives the publishing status update from the provider ABCS. If a failure occurs, the requestor ABCS updates the publishing status in OPH for the items and continues with the processing.
The requestor ABCS extracts pricing information from the items and prepares price list EBM for synchronizing pricing information.
The requestor ABCS invokes pricelist EBS to send pricing information for the items in the batch to Oracle BRM, where it is associated with the products by means of the synchronize product web services.
The price list response EBS is invoked to return a response to the requestor ABCS so that in case of failure, it updates the publishing status in OPH.
The requestor ABCS invokes the price list EBS to send pricing information for the products in the batch to Siebel. This is conditionally based on the ENTITY_TO_TARGET_APPLICATION domain value map (DVM) setup.
The Siebel provider ABCS receives the price list EBM and invokes the item composition EBS for creating additional products associated with billing events.
The item composition EBS invokes the SyncItemCompositionList provider service for creating the event products in Siebel (billing type as Event) in cases in which multiple charges are associated with the items that represent the billable products.
The item composition response EBS invokes the synchronize price list provider ABCS for Siebel to synchronize the pricing information on the product and the additional product that has been created for billing events.
The price list response EBS is invoked to return a response to the requestor ABCS so that in case of failure, it updates the publishing status in OPH.
If a BOM was published in the batch, the requestor ABCS queries the BOMs associated with the root item in the batch.
The requestor ABCS prepares a BOM EBM and for each target system (Siebel CRM and Oracle E-Business Suite) that needs to process the BOM, it invokes the BillOfMaterial EBS, which invokes the provider ABCS. Each provider ABCS (Siebel CRM and Oracle E-Business Suite) based on the ENTITY_TO_TARGET_APPLICATION DVM that is set up for every target application:
Receives the BillOfMaterials EBM and prepares the BOM ABM.
Invokes a web service on the application to synchronize the BOM.
Prepares the response with the publishing status for the individual items, which is sent back to the requestor ABCS.
The requestor ABCS updates the publishing status in OPH for the root items of the BOM published in the batch.
The assumption is that OPH always specifies target systems at the batch level. The GetTargetSystems OPH service returns all the target systems to which the batch should be published. If the target system is not listed in the GetTargetSystems response, the payload is not sent to it even if the system name is defined at the entity level. If an error occurs in the item adapter while the adapter is getting data from OPH, the synchronization process is stopped for the entire batch.
When chunking is enabled, the process splits the total entities in a batch to multiple chunks or sub-batch based on the BATCH_SIZE specified in the configuration property. Each of these chunks or sub-batches is processed as a batch by itself.
For more information, see Section 6.8, "Setting Configuration Properties".
Chunking can be enabled at the item or the BOM level, or for both. When chunking is enabled at the BOM level, the chunking extracts as many BOMs as defined in the chunk size. Additionally, if a BOM has an option class, the option class BOMs are also extracted into the same sub-batch. When chunking is enabled as part of the item synchronization process, if a sub-batch fails, all the items continue to be processed in that batch, but the pricelist or BOM is not processed. OPH provides a batch-level update that is called from the SyncItemPIMReqABCSImpl in case the batch synchronization fails.
For more information on optimizing performance by enabling item chunking or BOM chunking, see Appendix C, "User Defined Attributes Framework".
Figure 2-2 shows the technical implementation of the process:
Note:
This diagram is also applicable to Chapter 3, "Oracle Product Master Data Management Integration Option for Siebel CRM".
Table 2-1 describes the steps depicted in the sequence diagram.
Table 2-1 Item and BOM integration sequence steps
| Name | Step Description |
|---|---|
|
OPH item event is raised |
OPH item events are raised when the administrator publishes the items from the OPH system. This includes create/update to items or primary BOM associated with items The event contains a Batch_ID to represent a set of items that are published as a single payload. |
|
SyncItemListPIMEventConsumer |
SyncItemListPIMEventConsumer listens to business events and receives the WF_EVENT_T_msg event payload for item events. SyncItemListPIMEventConsumer routes to SyncItemListPIMReqABCSImpl with complete event payload. |
|
SyncItemListPIMReqABCSImpl |
The OPH requester ABC implementation SyncItemListPIMReqABCSImpl receives the event message from OPH and queries the target systems. It then transforms the event message to the OPH ItemQueryABM and calls the QueryItemListPIMAdapter to get the ItemListABM from OPH. The QueryItemListPIMAdapter response is then converted into SyncItemListEBM and SyncPriceListEBM and routed to the corresponding EBS service. Once the items/price list is synchronized in the participating applications, the status of the synchronization is sent back to the SyncItemListPIMReqABCSImpl, which updates OPH with the status. If the item synchronization is successful, only then is the BOM synchronized for that target. The SyncItemListPIMReqABCSImpl invokes the QueryBillOfMaterialsListPIMAdapter to get the BillOfMaterialsListABM, transforms the same into the SyncBillOfMaterialsListEBM, and routes it to the corresponding EBS. Once the BOM is synchronized in the participating applications, the status of the synchronization is sent back to the SyncItemListPIMReqABCSImpl, which updates OPH with the status. |
|
QueryItemListPIMAdapter |
This adapter service is implemented in business process enterprise library (BPEL). It is invoked from the SyncItemListPIMReqABCSImpl. It takes the batch ID as input and responds with the ItemListABM payload in that batch. It also implements the chunking of items into smaller batches based on the BATCH_SIZE configuration property in the AIAConfigurationProperties.xml. |
|
QueryBillOfMaterialsListPIMAdapter |
This adapter service is implemented in BPEL. It is invoked from the SyncItemListPIMReqABCSImpl. It takes the Batch_ID as input and responds with the BillOfMaterialsListABM payload in that batch. |
|
ItemEBSV2 |
Invoking the ItemEBSV2 with the SyncItemList operation routes the SyncItemListEBM to the SyncItemListSiebelProvABCSImpl, SyncItemListEbizProvABCSImpl, and SyncItemListBRMProvABCSImpl based on the target ID. |
|
SyncItemListEbizProvABCSImpl |
The SyncItemListEbizProvABCSImpl transforms the SyncItemListEBM into the appropriate Oracle E-Business Suite item ABM and invokes the appropriate application programming interface (API). The response from the Oracle E-Business Suite API is then transformed into the SyncItemListResponseEBM and sent back to the ItemResponseEBSV2. In this process, the cross-reference is linked to the Oracle E-Business Suite IDs of the product in the form of InventoryItemID::OrganizationID::OperatingUnitID. |
|
SyncProductSiebelProvABCSImpl |
The SyncProductSiebelProvABCSImpl transforms the SyncItemListEBM into the Siebel product message (without Promotion) and calls the Siebel product web service SWIProductImport to synchronize the product with all the items in the list, and performs these actions in sequence:
In this process, the cross-reference is linked to the Siebel product IDs into the ITEM_ITEMID cross-reference. In addition, the cross-reference is linked to the Siebel promotion IDs into the PROMOTION_PROMOTIONID cross-reference. |
|
ItemResponseEBSV2 |
The ItemResponseEBSV2 transmits the SyncItemListResponseEBM message back from the SyncItemSiebelProvABCSImpl, SyncItemEbizProvABCSImpl, and SyncItemListBRMProvABCSImpl to the SyncItemListPIMReqABCS, which then invokes the OPH status update service to update the item publication status in OPH. |
|
PriceListEBSV2 |
The SyncItemListPIMReqABCS converts the OPH item query response ABM into the SyncPriceListEBM based on the specification name Prod_Details_Definitions with a UDA Pricing_Code value other than NONE. It then passes the EBM message to the PriceListEBS, which routes the message to the ProductOptimizedSyncPriceListListSiebelCommsProvABCSImpl. |
|
ProductOptimizedSyncPriceListListSiebelCommsProvABCSImpl |
The ProductOptimizedSyncPriceListListSiebelCommsProvABCSImpl calls the Siebel SWIProductImport to synchronize the pricelist in Siebel and then sends the response back to the SyncItemPIMReqABCSImpl using the PriceListResponseEBS. |
|
PriceListResponseEBSV2 |
The PriceListResponseEBS routes the PriceListResponseEBM from ProductOptimizedSyncPriceListListSiebelCommsProvABCSImpl to the SyncItemListPIMReqABCS, which then updates the status to OPH. |
|
BillOfMaterialsEBS |
The SyncItemListPIMReqABCS invokes the BillOfMaterialsEBS with the asynchronous operation SyncBillOfMaterialsList if the item payload has the structure associated with it. The operation routes the SyncBillOfMaterialsListEBM message to Siebel CRM and Oracle E-Business Suite. Based on the routing rule, the BillOfMaterialsEBS invokes the SyncBillOfMaterialsListEbizProvABCSImpl and the SyncBillOfMaterialsListSiebelProvABCSImpl. |
|
SyncBillOfMaterialListSiebelProvABCSImpl |
The SyncBillOfMaterialListSiebelProvABCSImpl receives the SyncBillofMaterialEBM from the BillOfMaterialsEBS and calls the Siebel product service to synchronize the product structure in Siebel. It calls the Siebel promotion service to synchronize promotion structure, structure component exclusion, and transaction attribute exclusion and sends the response back using the BillOfMaterialListResponseEBS. |
|
BillOfMaterialListResponseEBS |
The BillOfMaterialListResponseEBS routes the synchronize BillOfMaterialListResponseEBM from the SyncBillOfMaterialListSiebelProvABCSImpl and the SyncBillOfMaterialListEbizProvABCSImpl to the SyncItemListPIMReqABCS, which calls the OPH update service to update the status of BOM published in OPH. |
|
SyncBillOfMaterialListEbizProvABCSImpl |
This service receives the BillOfMaterialEBM and calls the PLM API to synchronize the BOM in Oracle E-Business Suite. The SyncBillOfMaterialsListResponseEBM is then passed back to the SyncItemListPIMReqABCSImpl. |
This section includes the following sections:
Section 2.3.1, "Support for Routing Driven Through Explicit Specification of Target Systems"
Section 2.3.2, "Support for Multi-Language for Item Synchronization"
Section 2.3.3, "Support for Telecommunications Seeded Library Attributes"
Section 2.3.4, "Controlling Publishing of Items to Target System Instances"
Section 2.3.6, "Support for Updating Publishing Status in OPH upon Publication of Items"
This feature enables product administrators to specify the target systems explicitly in the Oracle Product Hub. Some of the changes made in Oracle Product Hub to a product or another entity apply only to one target system. Explicit specification prevents unneeded publishing of the payload to those target systems not affected by the changes.
This feature enables a more flexible, data-driven, and explicit approach for routing, and by doing so, reduces administration and maintenance costs and increases flexibility. At the batch level, a list of target systems is captured to identify the target systems that should receive the payload (for items, value sets, or product classes).
The list of target systems is used for routing the payloads to the target applications. AIA first maps the system IDs published by OPH to common system IDs and then uses these to route the payload to the target applications.
Within the published payload, some of the entities may not apply to some of the target systems. Each entity in the payload has an associated multi-row attribute that is used to identify the subscribing systems for the entity (implemented in OPH as a multirow UDA [AG: Destination_Sys_Specification]). This attribute identifies the systems that should process the specific entity within the batch. If Destination_Sys_Specification is instantiated and the destination system has the synchronize item flag set to Y, the items are synchronized to a participating application. If Destination_Sys_Specification is not instantiated, item is filtered out. The subscribing systems attribute is used for filtering rules for a given target system; these filtering rules are used to identify the payload entities pertinent to the specific target system.
The multi-language support (MLS) feature enables multi-language values for attributes to be published by OPH to target applications.
The MLS provides language codes and all the values in the corresponding languages for attributes that support language translation.
Some of the free-text fields on the items are translatable in the target applications, for example, Item Name, Description, and so on. For each translatable free-text field, OPH provides all the values in the supported languages and the corresponding language code for each value. The target applications may not support all the languages supported by OPH and thus consume only those values that belong to languages supported by the corresponding target applications.
Some of the free-text fields on the items are not translatable in the target applications. In this case, although OPH provides all the language codes and the corresponding values, the target application consumes in a single default language. This default language supported by the target applications must be configurable.
For the fields taking values from a valueset for which values are translatable, OPH provides the language-independent code and all the values in all the languages; however, AIA passes only language-independent code only to the target application.
For the fields with valuesets for which values are not translatable, OPH provides the code for the value that must be consumed by the target application.
For customer UDA, the values are synchronized with all the language codes and the corresponding values. The target applications have to consume these attributes based on the support offered for extended attributes.
The seeded attribute groups have attributes that define the characteristics of an item or the characteristics of an entity that the item represents. These attribute groups have been seeded in OPH. The process integration sets the values of these attributes in the corresponding target applications.
For more information about telecommunications seeded library attributes and their corresponding valuesets, see Appendix F: Seeded Item Metadata Libraries in the Oracle Product Hub Implementation Guide.
Product Details
Definitions: This attribute group is used to define the additional characteristics of an item that represents the product in Siebel. These are mapped to the first class attributes of the product in Siebel.
Marketing: This attribute group is used to define the marketing characteristics of an item that represents the product in Siebel. These are mapped to the first class attributes that represent the marketing details of the product in Siebel.
Service: This attribute group is used to define the service characteristics of an item. The service here refers to the customer service information for the item. These are mapped to the first class attributes that represent the customer service of the product in Siebel.
Logistics: This attribute group is used to store the logistics information of an item. These details are usually associated with the physical goods. These are mapped to the first class attributes that represent the logistics information of the product in Siebel.
Additional Information: This attribute group is used to define any additional information associated with the item. These are mapped to the first class attributes that represent the additional information of a product in Siebel.
Pricing
Simple Pricelists: This attribute group is used to define pricing-related data associated with the item in OPH. The pricing defined in this attribute group is not specific to an industry, and the model represents a framework to define a simple price on the items. The attribute group is used whenever a billing-specific, complex-rate-plan model is not necessary to represent the price on the item. The UDA pricing code is used to specify that the simple pricelists attribute group is used for defining the price on the item.
Promotion: The item in OPH can also represent a promotion.
More information: When an item represents a promotion, this attribute group is used to define additional information associated with the promotion. These are stored as a specification group in the ItemEBO of the canonical layer. These are mapped to the first class attribute of the promotion entity in Siebel.
Charge Plan: The item in OPH can also represent a promotion.
Nonrecurring Charge Details: When an item represents a promotion, this attribute group is used to define a charge plan associated with the promotion. This attribute group is specifically for the nonrecurring charges that are associated with the promotion. These are stored as specification groups in the ItemEBO of the canonical layer. These are mapped to the first class attribute of the promotion entity in Siebel.
Recurring Charge Details: When an item represents a promotion, this attribute group is used to define a charge plan associated with the promotion. This attribute group is specifically for the recurring charges that are associated with the promotion. These are stored as specification groups in the ItemEBO of the canonical layer. These are mapped to the first class attribute of the promotion entity in Siebel.
Charges, Adjustment, Usage Plan Details: When an item represents a promotion, this attribute group is used to define a charge plan associated with the promotion. This attribute group is specifically for the more advanced information of the promotion such as adjustments, certain usage plan details, and so on that are associated with the promotion. These are stored as specification groups in the ItemEBO of the canonical layer. These are mapped to the first class attribute of the promotional entity in Siebel.
Commitment: The item in OPH can also represent a promotion.
Charges Credits: When an item represents a promotion, this attribute group is used to define the commitment charges associated with the promotion. These are stored as specification groups in the ItemEBO of the canonical layer. These are mapped to the first class attribute of the promotion entity in Siebel.
Terms: When an item represents a promotion, this attribute group is used to define the commitment terms associated with the promotion. These are stored as specification groups in the ItemEBO of the canonical layer. These are mapped to the first class attribute of the promotion entity in Siebel.
Product Promotions
Upgrade: When an item represents a promotion, this attribute group is used to identify all the promotions to which the current promotion can be upgraded. These are stored as specification groups in the ItemEBO of the canonical layer. These are mapped to the first class attribute of the promotional entity in Siebel.
Subject Compatibility Rules: This attribute group is used to define compatibility rules associated with the item. This is a multi-row attribute group in OPH where multiple rules can be defined. These are stored as specification groups in the ItemEBO of the canonical layer. These are mapped to the first class attribute of the product entity in Siebel.
Destination System Specification: This attribute group is used to specify the target system to which the item is published. The attributes in this attribute group are not mapped to any field in the target application, but are used in decision-making, routing, or both.
Billing Attributes General: This attribute group is used to define billing-related information of the item for telecommunications. These attributes are primarily used in the integration to billing applications to create billing products. These have to be mapped to the first class attributes of the products in billing.
Billing Products Event Map: This attribute group is used to associate the charges with the billing products. In billing applications, charges are modeled as events called billable events. The association of the events to the billing products is represented by this attribute group.
These attribute groups together represent the complex rating structure associated with the communications-related billing products:
Rate Plan: The rate plan attributes associated with the billing products are represented in this attribute group.
Tier Group: This attribute group is used to define multi-tier rating for the billing products.
Day Time Range: This attribute group is used to define the day and time when the associated rate data must be applied. You define the day and time using calendar dates in this attribute group. This is a timezone-independent field in which the time range should not be translated across the systems in different time zones.
Days of the Week Range: This attribute group is used to define the day and time when the associated rate data must be applied. You define the day and time by specifying the weekdays in a range of calendar dates. This is a timezone-independent field in which the time range should not be translated across the systems in different time zones.
Rate Data: The actual rate or price is grouped under the rate data. You define certain discount brackets and proration details that apply to actual charges using this attribute group.
Balance Impacts: This attribute group defines the actual amount or charges that are associated with the billing products. The charges or the amounts can be grouped based on the type of resources, effective dates, and categories that can be defined in the billing application.
Billing Discount Attributes: When an item represents a billing discount, this attribute group is used to define the billing discount-related information.
Billing Discount Event Map: The association of the actual discount model with the discount is done by means of this attribute group.
For more information about communications-specific terminology, see Oracle Communications Billing and Revenue Management documentation.
Product Details: This attribute group is used to define communications-specific and fulfillment-related information of the item. These attributes are mainly used during order fulfillment processing.
These component UDAs have been seeded as part of the telecommunications library and are synchronized to the target application whenever a BOM structure is synchronized with the items:
Product Promotions: Components
Product Promotions: Pricing: Components: Adjustments
Component Pricing
Version: Structure
Product Promotions:Components: This component UDA is associated with the BOM that represents a promotion. It is defined for the immediate components of the item that represents a promotion. It does not apply to the children of the components. The item synchronization process sets the corresponding values in the context of the parent-child relationship of the promotion within Siebel.
Product Promotions: Pricing: Components: Adjustments: This component UDA represents the adjustments that are applied to the components of the item that represents the promotion. It is applied at the leaf-level component and is valid only in the context of the promotion. The process integration must set the values in the context of a promotion entity in Siebel.
Component Pricing: This pricing-related information of the component and subcomponents of the item that represents the promotion can be updated in context of the promotion. The hierarchy of items within the item synchronization is aware of the components and the associated pricing-related UDA. This component hierarchy is published by OPH. The integration sets these context-specific values for the corresponding subcomponents of promotions in Siebel.
Version: Structure: The component UDA provides more information about the structure that is associated with the BOM. It represents the contextual information of the BOM components. The process integration creates these as relationships in Siebel. The integration supports only two types of relationships: product and class. See Option Class Support in Item Synchronization for Siebel.
During the BOM synchronization, this contextual information is set in the target application for each of the components of the BOM. For example, in Siebel, this information is set for the relationship attributes of the product. The structure can also be associated with the item catalog categories in OPH. See Section 3.1.2, "Synchronization of Item Catalog Categories" for information about defining the structure for ICC for Siebel.
Multi-row attribute groups in OPH provide the flexibility to associate multiple sets of attribute values with the same object instance.
These multi-row attribute groups are seeded as part of the telecommunications library:
Pricing: Simple Price List
Commitment Charge Credits
Commitment Terms
Product Promotions Upgrade
Subject Compatibility Rules
Destination System Specification
Billing Products Discount Map
Rate Plan
Rate Data
Balance Impact
Tier Group
Day Time Range
Days of the Week Range
Billing Discount Event Map
During item publish, the multiple sets of attribute values associated with each of these attribute groups are published by OPH. The process integration includes the sets of attribute values within the canonical model. Supporting multi-row attribute groups in the target application is handled in the corresponding connector services.
Note:
Some of the applications can perform delete all and insert all operations. The interfaces on the target applications must be carefully designed and implemented based on the usage of this set of attribute values in the corresponding applications. For example, in Siebel, delete all and insert all cannot be performed on subject compatibility rules because the rules have references in other components.
You can define new multi-row attribute groups and the process integration includes them in the canonical model.
Note:
The integration to Siebel does not support customer-defined multi-row attribute groups.
There is support for Destination System Attribute Groups. Destination and target systems are defined below:
Destination Systems: The systems that are associated to the items using the seeded attribute group "Destination System Specification." These are always set in context of the item definition. It consists of an attribute (Flag) called Sync_Item When Sync_Item="Y", the item must be published to the corresponding system and when Sync_Item ="N", the item must not be published to the corresponding system.
Target Systems: The systems that are selected in the publication framework when a batch of items are published from Oracle Product Hub.
For example, a promotion may have bundles and other component items. The promotion and bundles must be published only to Siebel where the leaf level items must be published to both BRM and Siebel. In such cases, the destination system for items that represent the promotion and Bundles will have only Siebel whereas the leaf level items will have the Siebel and BRM. When the promotion is published from Oracle Product Hub in the publication framework, Siebel and BRM instances are specified as the target for the batch.
Table 2-2 shows a promotion that explains each option:
Whenever the destination systems are not set in context of the item, the items will be published to all the instances specified on the batch in the publication framework (target systems).
Whenever the destination systems are set in context of the item with Sync Item = "Y" and they match the target systems in the publication framework, then the items will be published to all the instances specified in the destination system attribute group with Sync Item = "Y" in context of the item (rare and upgrade cases).
Add only those systems to "Destination System Specification" attribute group for which the items are not published and set the Sync_item flag = N.
Use Table 2-3 to consider the following as the application instances: SEBL_1, BRM_1, BRM_2, BRM_3 as target application instances:
| Item | Item Type | Destination System | Sync Item |
|---|---|---|---|
|
<xxxx>Standard VoIP |
Promotion |
BRM_1 BRM_2 BRM_3 |
N N N |
|
<xxxx>VoIP Bundle |
Commercial Bundle |
BRM_1 BRM_2 BRM_3 |
N N N |
|
<xxxx>VoIP Service |
Service Bundle |
BRM_1 BRM_2 BRM_3 |
N N N |
|
<xxxx>Basic VoIP Access |
Product |
BRM_2 BRM_3 |
N N |
|
<xxxx>VoIP Voicemail |
Product |
BRM_2 BRM_3 |
N N |
|
<xxxx>VoIP $10 Monthly Discount |
Product |
BRM_2 BRM_3 |
N N |
|
<xxxx>VoIP Adaptor |
Product |
BRM_1 BRM_3 |
N N |
In the above example, only the systems for which the items will NOT be published are added into the destination system specification attribute group and have the flag set to N. Corollary - All items are always published to the Target system instance that does not exist in the "Destination System Specification" attribute group of the item.
Case 1: When the Promotion <xxxx>StandardVoIP is published in the publication framework all the systems SEBL_1, BRM_1, BRM_2 are specified as target systems.
All the items are published to SEBL_1
<xxxx>Basic VoIP Access, <xxxx>VoIP Voicemail, <xxxx>VoIP $10 Monthly Discount are published to SEBL_1 and BRM_1
<xxxx>VoIP Adaptor to SEBL1 and BRM_2.
The items are always published to the target systems specified in the publication framework that does NOT exist in the destination system attribute group.
Also note <xxxx>VoIP Adaptor is not published to BRM_3; BRM_3 exists in destination system attribute group, but is not specified as a target system.
Case 2: When the Promotion <xxxx>StandardVoIP is published in the publication framework all the systems BRM_1, BRM_2, BRM_3 are specified as target systems.
<xxxx>Basic VoIP Access, <xxxx>VoIP Voicemail, <xxxx>VoIP $10 Monthly Discount are published to BRM_1
<xxxx>VoIP Adaptor published to only BRM_2
None of the items are published to BRM_3
The items are not published to the target systems (BRM_3) that exist in the destination system attribute group.
Note:
If Customers already have item set up where the destination systems include systems which have Sync Item = Y and Sync Item = "N", ensure that the item is published to the corresponding target systems specified in the publication framework during the item publish process.
Update of the publish status in OPH enables a product administrator to know the results of the previous publish and allows republishing if needed. A publishing status is associated with an item and OPH provides services to update the publication history for items (for its publication to a given system within a batch). OPH provides a service to update the status of the entity. The publishing status values can be:
Batch Submitted - Initial status set by OPH for items before publication.
In Process - Status set by AIA once the data is fetched from OPH for processing.
Succeeded - Indicates that the item in a batch is successfully published to the target applications.
Failed - Indicates that the publication of the item to the target applications failed.
Ignored - Indicates that the item was ignored by a specific system because it does not apply to it, for example, promotions for BRM. This is set as a default value on the OPH side API to save processing complexity on the AIA side.
AIA updates the publishing status in OPH for items published within a batch once all the entities in the batch have been processed (both items and structures).
When the target system processes the entire payload at once (entire ListItemEBM or entire ListBOMEBM), the service to update status at the batch level is used; otherwise, a more granular service that updates the status at the entity level is used. For example, if an error occurs within AIA and the entire EBO cannot be processed, then a batch-level service is used. If the synchronize promotions services in Siebel fail, the status needs to be reported for each individual entity. When the target system offers services that are more granular than the submitted payload, but less granular than the items (such as Siebel or BRM), the status is still updated at the item level.
The publishing message contains two parts:
An initial string prepared by the AIA requestor giving the context of the service that the error occurred in.
The initial string is a message in English the purpose of which is to help the OPH product administrator understand in which context the message was generated. The publishing status is per combination of item and system to which the item is being published. In the context of an item publishing, multiple interactions may exist with a given system (for items, price list, and BOM). The prepended message provides this context and enables the product administrator to understand what went wrong.
The message returned by the target system or by the service provider.
The message returned by the target system or by the service provider may be an error message in case of failed synchronization or an informational message. When the target system is Siebel, the message also contains the workspace ID that was used in Siebel to publish the entities in the batch.
Status is published back to OPH by means of the responses to item, price list, and BOM synchronizations.
Oracle Product Hub artifacts used by this integration are:
Item Synchronization: Inbound Web Services
Service Name: ItemService
Operation Name: GetItemInformation
Request and response: ItemService_GetItemInformation, ItemService_GetItemInformationResponse
BOM Synchronization: Inbound Web Services
Service Name: ItemService
Operation Name: getStructureDetails
Request and response: ItemService_getStructureDetails, ItemService_getStructureDetailsResponse
Publication Service: Outbound Web Services
Service Name: PublicationService_Service
Operation Name: PublicationService_UpdatePublicationStatus
Request and response: PublicationService_UpdatePublicationStatus_InputMessage, PublicationService_UpdatePublicationStatus_OutputMessage
Operation Name: PublicationService_GetBatchSystems
Request and response: PublicationService_GetBatchSystems_InputMessage, PublicationService_GetBatchSystems_OutputMessage
Item Catalog Synchronization: Inbound Web Services
Service Name: ItemCatalogService
Operation Name: getICCDetails
Request and response: ItemCatalogService_getICCDetails, ItemCatalogService_getICCDetailsResponse
Operation Name: PublicationService_GetBatchSystems
Request and response: PublicationService_GetBatchSystems_InputMessage, PublicationService_GetBatchSystems_OutputMessage
Valueset Synchronization: Inbound Web Services
Service Name: ValuesetService
Operation Name: getValueSetDetails
Request and response: ValuesetService_getValueSetDetails, ValuesetService_getValueSetDetailsResponse
Product Class: Inbound Web Services
Service Name: SWIProductClassIntegrationIO
Operation Name: SWIClassImportUpsert
Request and response: SWIClassImportUpsert_Input, SWIClassImportUpsert_Output
Attribute Definition: Inbound Services
Service Name: SWIAttributeIntegrationIO
Operation Name: SWIAttributeImportUpsert
Request and response: SWIAttributeImportUpsert_Input, SWIAttributeImportUpsert_Output
These are the services delivered with this integration:
SyncItemCatalogCategoryPIMEventConsumer
SyncItemCatalogCategoryPIMReqABCSImpl
SyncItemListPIMEventConsumer
SyncItemListPIMReqABCSImpl
QueryItemListPIMAdapter
QueryBillOfMaterialsListPIMAdapter
SyncSpecificationValueSetListPIMEventConsumer
SyncSpecificationValueSetListPIMReqABCSImpl
For more information, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack: Development Guide, "Configuring and Using Oracle Enterprise Repository as the Oracle AIA SOA Repository."
A unique EBM ID is assigned to the SyncItemEBM and sent over the ItemEBS to the providers that synchronize the items in the participating applications and sends the response message back as SyncItemListResponseEBM. If no pricelist or BOM is available to synchronize, the workspace auto-release flag is also set on the ItemEBM so that the provider can release the workspace after the item synchronization is successfully completed. The SyncItemListPIMReqABCSImpl receives the response using correlation and then updates the OPH application with the item response status for every entity in the batch.
All applications that receive the price list have to be configured in this DVM during setup. The SyncPriceListEBM is routed to the target application providers only if item synchronization is successful and the target system is configured to receive the price list (ENTITY_TARGET_APPLICATION_MAPPING DVM). If no BOM is exists to be processed for that particular batch, the release workspace flag is also set and sent so that the provider can release the workspace after the price list synchronization is successfully completed. The provider ABCS synchronizes the pricelist in the respective applications and sends the response status back as the SyncPriceListResponseEBM. The SyncItemListPIMReqABCSImpl receives the response using correlation and then updates the OPH application with the pricelist response status.
If the event payload has STRUCTURE_FLAG as Y, the target system is configured to receive the bill of materials (ENTITY_TARGET_APPLICATION_MAPPING DVM), and the item synchronization is successful, then the SyncItemListPIMReqABCS calls the QueryBillOfMaterialsListPIMAdapter service. The SyncBillOfMaterialsListEBM is sent to the participating applications.
The SyncItemListPIMReqABCSImpl, using correlation, receives the SyncBillOfMaterialsListResponseEBM that is returned by the participating applications and OPH is updated accordingly. The release workspace flag is also set and sent to the provider. The provider releases the workspace after successfully synchronizing the BOM.
This BPEL adapter service receives the session ID, batch ID, mode, and system ID from the SyncItemListPIMReqABCSImpl and retrieves the item information from OPH in a chunk or in batch mode based on the configuration (BATCH_SIZE) defined in the AIAConfigurationProperties.xml. If the batch size is 0 (zero), then all the item details in batch are returned (in batch mode); otherwise, the number of items defined in the configuration (BATCH_SIZE) is returned in multiple iterations (in chunk mode).
This BPEL adapter service receives the session ID, batch ID, mode, and system ID from the SyncItemListPIMReqABCSImpl and retrieves the BillOfMaterial information from OPH in a chunk or in batch mode based on the configuration (BATCH_SIZE) defined in the AIAConfigurationProperties.xml. If the batch size is 0 (zero), then all the bill of material details in batch are returned (in batch mode); otherwise, the number of bill of materials defined in configuration (BATCH_SIZE) are returned in multiple iterations (in chunk mode).
The SyncSpecificationValueSetListPIMEventConsumer is implemented as a lightweight Mediator service. The SyncSpecificationValueSetListPIMEventConsumer has an Oracle applications adapter configured to listen for an OPH valueset publish business event. One service is available with one operation to read the OPH message SyncValueSetReqMsg from the Oracle AQ WF_BPEL_Q: SyncSpecificationValueSetListPIMEventConsumer. It is implemented as a Mediator process with an Oracle applications adapter for listening to a business event. OPH synchronizes valueset business event: oracle.apps.ego.extfwk.publishValueSet.
This service is a BPEL process. This accepts a valueset business-event message as a request and synchronizes valuesets in Siebel. The SyncSpecificationValueSetListPIMReqABCSImpl is a BPEL process that receives the OPH valueset event message from the SyncValueSetPIMEventConsumer service. This service is responsible for calling the OPH query (participating applications) valueset Web service, based on event payload. It transforms the OPH valueset ABM messages into the appropriate SyncSpecificationValueSetListEBM. It invokes SpecificationValueSetEBS (SyncSpecificationValueSetList operation) to synchronize valuesets in Siebel.
This asynchronous service accepts the OPH valueset event message as a request. It follows all the standards of a requester ABCS.
This single operation service accepts a SyncSpecificationValueSetListEBM message as a request. The responsibility of this service is to receive SyncSpecificationValueSetListEBM and transform the same into a Siebel attribute definition ABM and call the Siebel attribute-definition Web service. This service also filters the MLS mapping based on LANG_CODE_DVM. This DVM has the details about how many languages the provider system can support. Once the synchronization is done, it gets the response message and passes the response to SpecificationValueSetResponseEBS.
The assumptions and constraints for Oracle Product Hub are:
Oracle Product Hub is the master for definition of items, BOMs, and metadata. Any changes or enrichment that may occur in the participating application are not synchronized back to Oracle Product Hub.
The integration does not support synchronization of products from an inventory organization that is shared among multiple operating units.
Item catalog category cannot be published as a batch. Each ICC has to be manually published to the downstream systems; however, all ICCs that are part of hierarchies can be published together.
The parent ICC associated with an item catalog category cannot be changed once it is released. The parent ICC cannot be changed even to create a new version. This is an OPH limitation.
The same item cannot be added as a component of a BOM Item. This is an OPH limitation.
The MLS support offered by OPH for the valuesets depends on the validation type associated with the valueset. The validation types independent and translatable are supported for this release.
OPH does not support Boolean and Integer data types. To support Boolean and integer datatypes, the product administrator needs to suffix the valueset name with the word _BOOL and set predefined values, for example, True or False. The product administrator can define any number of Boolean valuesets using the technique, but the values must always be same, and seeded.
Publishing alternate catalogs from Oracle Product Hub is not supported by the integration.
Variant type attribute group in OPH is not supported by the integration.
OPH does not support adding the same item as component of BOM more than once. Siebel and process integration do support these. This is an OPH limitation. If required, this can be achieved by using the operation sequence support provided by OPH.
|
 Copyright © 2001, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
