Skip Headers
Oracle® Application Integration Architecture Oracle Product Master Data Management Integration Implementation Guide
Release 11.1

Part Number E27426-03
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

3 Oracle Product Master Data Management Integration Option for Siebel CRM

Siebel CRM is available as an installation option in the Product MDM integration.

This chapter includes the following sections:

3.1 Supported Features

These are the supported features for the Siebel option:

The following process flows are supported from Oracle Product Hub to Siebel CRM as part of the item and BOM Synchronization:

  1. Synchronization of Products and Discounts and Associated Structures from Product Hub to Siebel CRM.

    1. Support for Transaction Attributes in Product Synchronization.

    2. Support for Class type structure/ relationship for Siebel CRM.

    3. Support for Controlling Auto-Release of Entities Published from Oracle Product Hub in the Same Batch for Siebel.

  2. Synchronization of Promotions from Product Hub to Siebel CRM.

For more information about Siebel CRM, see the Siebel CRM product documentation.

3.1.1 Synchronization of Metadata

Metadata enables customers to predefine various characteristics for the products that facilitates faster introduction of new product variants, reduces the time to market, and results in significant savings on initial and maintenance costs and support for product differentiation offering cross-sell and up-sell opportunities.

The metadata synchronization supports these features:

  • Synchronization of Item Catalog Categories

    • Synchronization of Relationships and 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

    • Association of Item Catalog Category with Items

    • Publish of Item Catalog Category from OPH to Siebel CRM Implementation Flow

  • Synchronization of Valuesets

    • Synchronization of Valuesets as part of Item Catalog Categories

    • Synchronization of Valuesets Independently

    • Batch and Initial Load

    • Multilanguage Support for Valuesets

All these synchronization processes report the status to OPH publication history.

3.1.2 Synchronization of Item Catalog Categories

The publication framework of OPH provides a user interface to publish item catalog categories (ICC) to one or more participating applications. The participating applications have to be registered within the publication framework of Oracle Product Hub.

A new ICC is created in OPH as a draft version and it is released, creating a working or active version of the ICC. Similarly, during updates, the draft version is updated and released to create a new version of ICC in OPH. However, at any given point, only one active released version of the ICC exists.

During the ICC publish, the active released versions or the future-dated versions of the ICC are published one at a time to the downstream participating applications (that is, one ICC per publish process). The publishing of ICC is a manual process performed by the OPH product administrator.

The publish action invokes the integration process and provides basic information of ICC such as the ICC unique identifier. The integration process queries OPH and the OPH interfaces provide complete details of the ICC and all the following associated entities.

  1. Item Catalog Categories (ICC)

  2. Attribute Groups

  3. Seeded Attributes and Custom added Attributes

  4. Transaction Attributes

  5. Valuesets

  6. Structure/Relationship associated with ICC

The integration supports both create and update operations for ICC.

  • For the create operation, the integration creates a workspace version of the product class in Siebel CRM.

  • For the update operation, the existing product class is updated. The updates include changes to the product-class core fields-adding, deleting, and updating structure and relationship, and adding, deleting, and updating transaction attributes and valuesets.

Once the product class has been successfully created in Siebel, the status is sent back to OPH. OPH maintains a publication history for all the versions of ICC for each downstream application.

In cases in which a version ICC is republished without any changes from OPH to Siebel CRM, the updates on the product class do not create a new version in Siebel CRM.

The versions of ICC in OPH are associated with the effective start and end dates. Only the active released version or future-dated versions can be published from OPH publication framework.

The following versions cannot be published from OPH:

  • Expired or past versions - effective end dates are earlier than the current date.

  • Draft version - versions that are not yet released.

A provision exists to revert to the earlier version of the ICC. For this, a new version with effective dates must be created in OPH. No impact occurs to the integration with the creation of this new version because the integration process handles this as new versions.

Auto-Release of Entities

The auto-release provision is provided by OPH. The auto-release is activated by default. The product administrator in OPH can update it based on the modeling. Siebel releases the entity if the value is set or it must create the workspace version of the entity. The auto-release is supported for synchronize operations.

For more information about auto-release, see Section 3.1.19, "Support for Controlling Auto-Release of Entities Published from Oracle Product Hub in the Same Batch for Siebel".

3.1.3 Synchronization of Relationships and Structure Under Item Catalog Categories

An ICC can be defined with relationship and structure that contains items and BOMs.

  • The ICC can be defined with items or BOMs as the relationships. When the integration queries OPH for the ICC, the structures that are defined as relationships with the ICC are also returned. The ICC has references only to the latest version of the structure because the structure has already been successfully published to the downstream application. The integration creates relationships for the product classes in Siebel.

  • The items or BOMs are synchronized to the target applications before the ICC is synchronized; otherwise, the integration process fails.

  • The query also returns the component UDA associated with the relationship. This component-UDA stores context-specific values for the relationship within the ICC, for example, min, max, default value, and so on. The integration uses the references to create relationships within Siebel, add corresponding products, and set the context-specific values specified by the component UDA within the context of the product class in Siebel.

  • All types of BOMs can be added as the relationship for the item catalog categories.

This is an example of how various relationships under ICC are handled by the process integration. This is similar to the relationship handling of items in Option Class Support in Item Synchronization for Siebel CRM.

The structure definition in OPH for item catalog categories supports two types of parent-child relationships:

  • Relationship of domain type as product: The product relationship represents another item that is related to the root item.

  • Relationship of domain type as class: The class relationship provides a list of items that can be treated as options. In OPH, these items are defined as BOM with BOM item type as option class, and the options are added as components of the BOM.

Note:

Domain type is a UDA associated with the item that identifies the type of relationship.

For more information about telecommunications seeded library attributes and their corresponding valuesets, see "Appendix F: Seeded Item Metadata Libraries, Communications Product Details Library - Vertical" in the Oracle Product Hub Implementation Guide.

Table 3-1 is an example of how product and class type relationships are supported in OPH and how the process integration creates them in Siebel:

Wireless Service ICC

Wireless Router (Item)

Bluetooth devices (Item with an option class type BOM and entity type of option group)

Samba Bluetooth Headset

B-Micro Bluetooth Headset

Table 3-1 Product and class types

Wireless Router Class Wireless Router

Wireless Device Accessory

Bluetooth devices

Wireless Device Accessory

Samba Bluetooth Headset

Wireless Device Accessory

B-Micro Bluetooth Headset


Table 3-2 depicts the OPH definition of the relationship in the seeded attribute group Version Structure associated with the Wireless Service ICC. These attributes are component attributes values the values of which are set in context of the Wireless Service ICC.

Table 3-2 Attributes

Relationship Name Domain Type Product Class Default Cardinality

Relationship1

Product

Wireless Router

1

NA

Relationship2

Class

Bluetooth devices

Wireless device accessory

1


For product relationships, the process integration creates a relationship of type product in Siebel for the Wireless Service ICC. This relationship has an empty relationship domain in Siebel.

For class relationships, the process integration creates a relationship of type class and adds all the components of the Bluetooth devices as the relationship domain. The product (Bluetooth devices) is not included as a part of the relationship in Siebel.

This is an example of the support for relationship for product class in Siebel:

Wireless Service ICC

Relationship1 Wireless Router

Relationship2 Wireless device accessory

Samba Bluetooth Headset

B-Micro Bluetooth Headset

Table 3-3 shows the structure attributes of the Wireless Service ICC in Siebel:

Table 3-3 Structure attributes

Relationship Name Domain Type Product Class Default Cardinality

Relationship1

Product

Wireless Router

NA

1

Relationship 2

Class

NA

Wireless device accessory

1


Table 3-4 Relationship domain

Relationship Domain Quantity

Samba Bluetooth Headset

X

B-Micro Bluetooth Headset

X


To update the relationship domain, more product components can be added to the product Bluetooth devices, and all the item catalog categories that have class relationship with Bluetooth devices must be synchronized to Siebel for the relationship domain to be updated. Updating the Bluetooth devices and the synchronization is a prerequisite.

Any change in the relationship creates a new version of Wireless Service ICC in OPH. The process integration updates the corresponding Wireless Service ICC and the relationship in Siebel CRM.

3.1.4 Synchronization of Attribute Groups as Part of Item Catalog Categories

Every ICC is associated with zero or more attribute groups. Attribute groups are not defined within a context of the ICC and are reused across ICCs. Attribute groups are used to categorize user-defined attributes and operational attributes. The child ICC inherits the attribute groups of the parent ICC. The attribute groups are published when the associated ICCs are published. In the current release, OPH does not maintain the publication status of the attribute group in the publication history.

Whenever the integration queries OPH for the ICC, the attribute groups associated with the ICC are also returned. The attribute groups are represented at the canonical layer (specification group) as a part of classification scheme EBM. The attribute groups have reference attributes (specification).

None of the entities corresponds to attribute groups in Siebel; therefore, they are ignored at the Siebel connector service in the integration.

Note:

OPH provides a seeded telecommunications library that consists of a set of predefined attribute groups consisting of attributes that have predefined mapping to the fields of the item in the downstream application (Siebel). Updates to these seeded attribute groups and the associated attributes are not supported by the OPH. In addition, the integration does not support addition or deletion of attributes within seeded attribute groups; however, you can define new attribute groups and attributes.

New attribute groups with attributes can be defined. The integration differentiates between the customer-defined UDA and the seeded UDA and creates these as flex field attributes in Siebel. Whenever customer-defined UDA is updated or new attributes are added, all the ICCs that are associated with the attribute groups have to be republished to the downstream applications.

Attribute groups can be of type multi-row. A multi-row attribute group is used to define characteristics that are record-based such as rules, pricelist lines, and so on. See the telecommunications seeded library attributes for definitions of multi-row seeded attribute groups.

When multi-row attribute groups are published, OPH provides the complete definition of these attribute groups with the records. The integration supports these multi-row attribute groups in the canonical model, but ignores them at the Siebel connector. (The values for the multi-row attribute groups are defined during item definition and are set in the downstream applications during the item synchronization process.)

3.1.5 Synchronization of Customer UDA as Part of Item Catalog Categories

The UDAs are defined within the context of the attribute group. These are not versioned entities. The UDAs are associated with valuesets. Context-specific values are set for every UDA within the attribute group. The child ICC inherits these UDAs from the parent ICC.

The static UDA, component UDA, and operational attributes are published with the attribute groups when the corresponding ICC is published.

Whenever integration queries OPH for ICC, the UDAs that are associated with the ICC through attribute groups are returned along with the ICC definition and other entities. The attributes that exist across the attribute groups are extracted and grouped under canonical models of the attribute.

Siebel does not have attributes as separate entity. The static UDA and operational attributes that are defined within attribute groups are ignored in the Siebel connector. These attributes have fixed mapping with the product fields in Siebel and Oracle E-Business Suite respectively. The values for these fields are set during item synchronization.

Note:

UDAs are defined within the context of the attribute group. Any updates to the UDA results in the update of the attribute group. The ICC has to be republished for the updates on the UDA.

All customer-defined UDAs are stored in the flexfield support provided by CRM; therefore, the customers must ensure that they define unique attributes across custom attribute groups. The recommended approach is to prefix the corresponding attribute group name with XX for every customer-defined attribute. All the customer-defined attribute groups that are defined without a prefix are not mapped to any target application, but are available in the AIA layer. Customers have to extend the connector services to map these attributes to the target applications.

The OPH does not track the publication status for attributes in the publication history for UDA.

3.1.6 Synchronization of Transaction Attributes as Part of Item Catalog Categories

Note the following:

  • The transaction attributes are defined within the context of the ICC in OPH. These are not versioned entities. The transaction attributes are associated with versioned valuesets in OPH. Context-specific values are set for every transaction attribute within the ICC. The child ICC inherits the transaction attributes and the valueset from the parent ICC.

  • Whenever the integration queries the OPH for ICC, the transaction attributes that are associated with the ICC are also returned. The integration process extracts all the transaction attributes and includes them in the specification section of the classification composition EBM. The process integration creates these as attributes of the product class in Siebel and sets the corresponding context-specific values.

  • Any changes in the transaction attributes associated with the ICC (add, delete, or update the context specific values) updates the ICC and a new version is released in OPH. When an updated ICC is published, the integration updates the corresponding product class with the transaction attributes in Siebel CRM.

  • The static attributes and the transaction attributes both are grouped within the canonical model. The static attributes in the specification is ignored by the Siebel connector and the transaction attributes are created as product class attributes.

  • Duplicate transaction attributes cannot be defined within an ICC. If a similar transaction attribute is defined in a parent ICC and the one of its child ICC in the hierarchy, the definition in the child hierarchy overrides the definition of the inherited transaction attribute.

  • If the inherited transaction attribute is updated in the child ICC, the transaction attribute does not remain an inherited attribute. It becomes a native attribute of the child ICC.

3.1.7 Transaction Attributes without Valuesets

Transaction attributes are associated with valuesets and the values for the transaction attributes are selected from the list during order capture. For some transaction attributes, the values can be freeform text. For such transaction attributes, a valueset may not be associated in certain applications. For example, Oracle Product Hub.

In Oracle Product Hub, a transaction attribute is created in context of an item catalog category. The transaction attributes may or may not be associated with versionable valuesets. The following are the data types supported for the transaction attributes:

  • Char

  • Number

  • Datetime

  • Standard Datetime

  • Translatable Text

For the transaction attributes of the first four data types associating the valueset is not mandatory but a valueset can be associated in Oracle Product Hub. However, for a transaction attribute of data type 'Translatable Text' a valueset cannot be associated. This is restricted with the validations in Oracle product Hub.

To support transaction attributes with no valuesets as part of the Item Catalog Category synchronization to Siebel the following design approach has been implemented:

  1. Create an attribute definition with the data type = "Text" and domain type = "Freeform" in Siebel.

  2. Update the details of the attribute definition in AIA Configuration file.

During the Item Catalog Synchronization from OPH to Siebel, if a transaction attribute has no valueset associated with it, then the process synchronization will read the attribute definition from the configuration file and will set the corresponding attribute definition as the valueset for the transaction attribute in Siebel.

Subsequent updates to Item Catalog categories, for instance, the addition or deletion of transaction attributes or items in the structure will not affect the transaction attributes in Siebel.

3.1.8 Synchronization of Item Catalog Category Hierarchies

Note the following:

  • The publication framework for ICC provides flags that provide these publishing options for the product administrator in OPH:

    • Publish only the selected ICC.

    • Publish selected ICC and all its parents.

    • Publish selected ICC and all its children.

    • Publish selected ICC and all its parents and children.

  • In cases in which a single ICC is selected for publishing, if that ICC has a parent ICC that is not published, the parent ICC must be published to the downstream applications. If not, the process integration fails. You must publish the parent ICC and republish the child ICC. In this case, the child ICC references the parent ICC. The integration process associates the child ICC and its parent in Siebel. Alternately, whenever a parent ICC is updated, the product administrator must publish the complete hierarchy associated with the ICC.

  • In cases in which the flag to publish the entire hierarchy (parents or children; or parents and children) is set, the integration process queries OPH for all the ICCs in the hierarchy. OPH returns the complete definition of all the ICCs in the hierarchy. The standard methodology to publish the entire hierarchy (parents and children) is recommended. The integration process creates the complete hierarchy of all the product classes in Siebel.

  • Whenever an ICC is updated in OPH and published to downstream applications, the integration updates the existing product classes. In addition, the corresponding hierarchy is updated in Siebel using the references to children or parent classes. The product classes are released to reflect the hierarchy in the active version.

  • The structure, transaction attributes, and the attribute groups of the parent ICC are passed to the child ICC. The inherited structure in the child ICC can be updated, for example, cardinality. Whenever an inherited structure is updated in the context of the child, the inheritance breaks and the structure becomes a native relationship of the child ICC. The behavior is the same for transaction attributes. The process integration updates the corresponding entities in the downstream applications.

3.1.9 Association of Item Catalog Category with Items

An item catalog category can be associated with the items. The items inherit the static attributes, transaction attributes, and structure associated with the item catalog category. An item can be associated with only one item catalog category.

  • When items are published in the publication framework, a reference to the item catalog category is published with the item.

  • The process integration creates the association of item and the ICC during the item synchronization process.

3.1.10 Publishing of Item Catalog Category from OPH to Siebel CRM Implementation Flow

Figure 3-1 shows the high-level integration flows for the item catalog category (ICC) synchronization:

Figure 3-1 Synchronization of ICC/Product Class created in OPH

Sync of ICC/Product Class

These are the synchronization steps:

  1. The product administrator in OPH publishes the ICC from the publication-framework user interface. The process publishes an event and provides basic information about ICC. The event consumer process invokes the requester ABCS for OPH.

  2. The requester ABCS queries the target applications from OPH by calling the get target systems service.

  3. Once the target systems are retrieved, the requester queries the ICC definition from OPH by calling the OPH Query ICC interface. The OPH Query ICC interface returns the complete information of the ICC together with the complete definitions of the associated entities (attribute groups, attributes, and valuesets). Valuesets are independent entities and can be associated with different attributes within the same or different attribute group in an ICC.

  4. The OPH requester connector service transforms the response from the OPH query ICC interface into the SpecificationValuesetListEBM and ClassificationSchemeListEBM. The ClassificationSchemeListEBM has complete definitions of ICCs, attribute groups, attributes, and their associated valuesets. The connector service invokes an enterprise business service and provides the SpecificationValuesetListEBM as the input.

  5. The specification valueset enterprise business service routes to the appropriate synchronize attribute definition Siebel provider ABCS.

  6. The attribute definition class Siebel provider ABCS invokes the API provided by Siebel to create the corresponding attribute definitions in Siebel.

  7. The Siebel synchronize attribute definition returns to the caller with indication of success or failure.

  8. Once the response is returned by the synchronize attribute definition API, the Siebel connector service invokes a response EBS.

  9. The specification valueset response EBS returns the response to the requestor ABCS. The OPH requester ABCS transforms the valueset response EBM and invokes the OPH service to update the status. The OPH service updates the publication history for the valueset.

  10. The OPH requester ABCS invokes the ClassificationSchemeEBS and provides ClassificationSchemeListEBM as input.

  11. The ClassificationSchemeEBS routes to the appropriate synchronize product class Siebel provider ABCS. It invokes the API provided by Siebel to create product classes and their attributes. The product class also has structure or relationships associated. The relationships are created based on the relationship type.

  12. The synchronize product class API returns the status to the connector service.

  13. The Siebel connector service invokes a response EBS.

  14. The ClassificationSchemeResponseEBS sends the status back to the requester ABCS.

  15. The OPH requester ABCS transforms the classification scheme response EBM and invokes the OPH service to update the status. The OPH service updates the publication history for the ICC.

This diagram illustrates the services and their interaction.

Figure 3-2 Synchronization of ICC in OPH

Sync of ICC in OPH

Table 3-5 Sequence steps

Steps Name Step Description

1

OPH ICC publish event is raised from the OPH System

OPH ICC publish events are raised when the product administrator publishes the ICC from the OPH system.

2

SyncItemCatalogCategoryPIMEventConsumer

SyncItemCatalogCategoryPIMEventConsumer listens to the business event and receives the WF_EVENT_T_msg event payload. SyncItemCatalogCategoryPIMEventConsumer routes to SyncItemCatalogCategoryPIMReqABCSImpl with complete event payload.

3

SyncItemCatalogCategoryPIMReqABCSImpl

The OPH Requestor, SyncItemCatalogCategoryPIMReqABCSImpl, receives the event payload and calls the OPH publication service to get the list of target applications by passing the batch ID. It then constructs the query ICC OPH ABM, calls the OPH query ICC web service, and gets the complete ICC details.

It transforms the Query ICC response message to SyncSpecificationValueSetListEBM (only if valuesets are associated with T-Attr in OPH and the SyncValueSet flag is set to True in AIAConfigurationProperties.xml) and SyncClassificationSchemeListEBM.

If valuesets are associated with T-Attr and the valueset synchronize property is set to True in the AIAConfigurationProperties.xml, SyncItemCatalogCategoryPIMReqABCSImpl invokes SpecificationValueSetEBS, passing SyncSpecificationValueSetListEBM to synchronize valuesets in Siebel and other participating applications.

Once the valueset synchronization is done successfully, it calls the classification scheme EBS passing SyncClassificationSchemeListEBM to synchronize the ICC.

It gets the ICC synchronization response, constructs the OPH publication service ABM, and calls the OPH publication web service.

3.1

OPH Publication Service (PublicationService_GetBatchSystems)

This service takes the batch ID and gives the list of the target systems to which the synchronization should be done.

4

OPH Query ICC web service

OPH Query ICC web service receives the batch ID, publishes parent hierarchy and child hierarchy flags, and returns the ICC details associated with that batch.

5

SpecificationValueSetEBS

SpecificationValueSetEBS receives SyncSpecificationValueSetListEBM as an input and routes it to the SyncSpecificationValueSetListSiebelProvABCSImpl service to synchronize valuesets.

6

SyncSpecificationValueSetListSiebelProvABCSImpl

SyncSpecificationValueSetListSiebelProvABCSImpl receives SyncSpecificationValueSetListEBM. It transforms the EBM into the SyncAttributeDefinition ABM and calls the Siebel valueset-synchronization Web service. Once synchronization is done, it gets the response from the Siebel system, transforms SyncSpecificationValueSetEBM to SyncSpecificationValueSetResponseEBM, and invokes SpecificationValueSetResponseEBS.

7

Synchronize Attribute Definition Siebel Web service

Synchronize attribute definition Siebel Web service synchronizes the attribute definition in Siebel.

8

SpecificationValueSetResponseEBS

SpecificationValueSetResponseEBS receives SyncSpecificationValueSetListRespEBM as input and routes it to the SyncItemCatalogCategoryPIMReqABCSImpl service.

9

ClassificationSchemeEBS

Once the valueset synchronization is done successfully in Siebel, SyncItemCatalogCategoryPIMReqABCSImpl calls the ClassificationSchemeEBS passing SyncClassificationSchemeListEBM as its input and routes it to the SyncClassificationSchemeListSiebelProvABCSImpl service.

10

SyncClassificationSchemeListSiebelProvABCSImpl

SyncClassificationListSiebelProvABCSImpl receives SyncClassificationSchemeListEBM. It transforms the EBM into a SWIClassImportUpsert_Input message and calls the Siebel product-class synchronization web service to synchronize simple product class along with attributes or structures if associated.

It then populates the cross-reference with the corresponding Siebel IDs. Once this is done, it checks for any associated hierarchy. If it exists, it makes another call to the same Siebel Web service passing hierarchy information. Once synchronization is done, based on the workspace auto-release flag (Y), it calls the Siebel product-class synchronization service again and passes the workspace auto-release flag. It then constructs the SyncClassificationSchemeListResponseEBM and passes it to ClassificationSchemeResponseEBS.

11.1

Synchronize Product Class Siebel Web service

Synchronize product class Siebel Web service synchronizes the product class in Siebel and returns the response message.

11.2

Siebel workspace release Web service

Once the product class synchronization is done in Siebel, SyncClassificationSchemeListSiebelProvABCSImpl calls the Siebel product-class synchronization Web service again, passing workspace name, workspace refuse flag, and workspace auto-release flag to release the workspace.

12

ClassificationSchemeResponseEBS

ClassificationSchemeResponseEBS gets the SyncClassificationSchemeListResponse message and routes it to SyncItemCatalogCategoryPIMReqABCSImpl.

13

OPH Publication Service

Once the OPH requestor gets the ICC synchronization response message, it calls the OPH ICC publish status Web service to update the publication status in OPH. These are the possible status values:

Failed

Succeeded

Partial Fail (in case valueset fails)


3.1.11 Synchronization of Valuesets

The valuesets can be published independently or during the ICC publish from the OPH publication framework. The valuesets can be associated with the static UDA, customer UDA, and transaction attributes. For all the seeded valuesets of the telecommunications library, the integration provides DVMs. For all the valuesets that are associated with the transaction attributes, the integration with Siebel creates the attribute definitions.

Valuesets associated with the customer-defined UDAs are handled as freeform values with the corresponding language codes. The MLS support for the valuesets depend on the validation type associated with the valueset. Section 3.1.15, "Multi Language Support for Valueset Synchronization"

3.1.12 Synchronization of Valuesets as Part of Item Catalog Categories

Note the following:

  • Whenever the integration queries OPH for the ICC that is published, the valuesets that are associated with the attributes of the ICC are returned.

    Note:

    This includes the nonversionable valuesets that are associated with the UDA within the attribute groups and the versionable valuesets associated with the transaction attributes. In addition, if the same valueset is associated with more than one attribute, OPH returns a unique set (union) of valuesets associated with the ICC.

  • The integration supports only the synchronize operation.

  • In cases in which a versioned valueset is republished to Siebel CRM, the updates on the attribute definition do not create a new version in Siebel CRM. Once the attribute definitions are created, they are associated with the corresponding attributes of the product classes in Siebel.

  • Even though the canonical model consists of valuesets associated with the UDA and the transaction attributes, the Siebel connector ignores all the valuesets that were associated with the UDA and creates attribute definitions for all the valuesets that were associated with the transaction attributes. The integration provides DVMs for all the valuesets that are associated with the seeded attributes of the telecommunications library.

  • Whenever an ICC is published, the publication framework extracts the version of all the valuesets that were associated when the ICC was released, implying that the version of the valueset that was associated with the ICC when the ICC was created might differ from the active released version of the valueset; therefore, publishing always picks up the version of the valueset that was associated when the ICC was released. The version in the downstream application is driven by the versions that are published. No one-one mapping exists between the versions of entities in OPH and the downstream applications. OPH provides validation to ensure that only the released version of the valueset can be associated with the attribute.

3.1.13 Synchronization of Valuesets Independently

Note the following:

  • The publication framework provides a separate user interface to search and to publish the valuesets. Multiple versions of the valueset exist in OPH, but at any point, only one active released version of a valueset exists. Only the active released version and the future-dated versions of the valuesets can be published. OPH enables you to publish one or more valuesets per publish process to the downstream participating applications. The publishing of valuesets is a manual process performed by the OPH product administrator.

  • The publish action invokes the integration process and provides basic information about valuesets. The integration queries OPH for the complete details of all the valuesets.

  • In cases in which a version valueset is republished to Siebel CRM, the updates on the attribute definition do not create a new version in Siebel CRM.

  • The versions of valuesets in OPH are associated with the effective start and end dates. Only the active released versions or future-dated versions are published.

  • Draft versions-versions that are not yet released-cannot be published from OPH.

  • Once the attribute definitions are successfully created in Siebel for versionable valuesets of OPH, a status is propagated back to OPH. OPH maintains the publication history for all the versions of valuesets for each downstream application.

  • OPH supports these data types:

    • Char

    • Number

    • Standard Date

    • Standard Date time

    • BOOL (OPH does not support the Boolean type. If the valueset name has a BOOL suffix, it is treated as a Boolean type)

    • INT (OPH does not support the Integer type. If the valueset name has an INT suffix, it is treated as an Integer type)

  • Siebel supports all of these data types as well as Boolean and Integer data types except Datetime.

Figure 3-3 illustrates the valueset publish from OPH to Siebel CRM.

Figure 3-3 Valueset publish from OPH to Siebel CRM

Valueset publish from OPH to Siebel

These are the steps depicted in the diagram.

  1. The product administrator in OPH publishes one or more valuesets from the publication-framework user interface. The process publishes an event and provides basic information about the valuesets. The event consumer process invokes the requester ABCS for OPH

  2. The requester ABCS queries the OPH valueset service.

  3. The OPH valueset service returns a single payload with all the valuesets to the OPH requester ABCS.

  4. The OPH requester ABCS extracts all the valuesets and transforms them into a single SpecificationValuesetListEBM. It invokes an enterprise business service with the synchronization operation and provides the SpecificationValuesetListEBM as input.

  5. The enterprise business service routes to the appropriate provider ABCS.

  6. The Siebel provider ABCS transforms the incoming SpecificationListEBM into attribute definitions. The Siebel provider ABCS invokes the Siebel interfaces.

  7. The Siebel interface creates the corresponding attribute definitions. It checks the workspace auto-release flag: If it is Y, it calls Siebel Web service to release workspace. If it is N, the workspace is not released. In case of D (default behavior), it reads release workspace from AIAConfigurationProperties.xml. The interface returns to the caller.

  8. The Siebel provider ABCS sends the status through a response EBS.

  9. The response enterprise business service routes to the appropriate update valueset publish status OPH provider ABCS.

  10. The update valueset publish status OPH provider ABCS invokes the OPH update status Web service and provides the valuesets and the corresponding statuses. The OPH update status service updates the publication history to reflect the status of publish.

Figure 3-4 illustrates the services and their interactions:

Figure 3-4 Valueset publish from OPH to Siebel CRM

Valueset publish from OPH to Siebel CRM

Table 3-6 shows the sequence steps:

Table 3-6 Sequence steps

Name Description

OPH valueset event is raised from the OPH system

OPH valueset events are raised when the product administrator publishes the valuesets from the OPH system.

Valuesets can be published in batches.

SyncValueSetPIMEventConsumer

SyncValueSetPIMEventConsumer listens to the business event and receives the WF_EVENT_T_msg event payload for the valueset event. SyncValueSetPIMEventConsumer routes to SyncSpecificationValueSetListPIMReqABCSImpl with complete event payload.

SyncSpecificationValueSetListPIMReqABCSImpl

The OPH requester ABC implementation service, SyncSpecificationValueSetListPIMReqABCSImpl, takes the batch ID from the WF_EVENT_T ABM payload, queries the get target systems service, and calls the Query valueset OPH service to get the response.

SyncSpecificationValueSetListPIMReqABCSImpl service also calls the query target application's OPH service and gets the response back. It counts the target applications from response, and based on the count it constructs the EBM for applications.

SyncSpecificationValueSetListPIMReqABCSImpl service transforms the Query valueset OPH service response ABM into QuerySpecificationValueSetList EBM and calls the SpecificationValueSetEBS Service.

SpecificationValueSetEBS

SpecificationValueSetEBS Service gets SyncSpecificationValueSetList EBM as its input and routes it to the SyncSpecificationValueSetListSiebelProvABCSImpl service.

SyncSpecificationValueSetListSiebelProvABCSImpl

SyncSpecificationValueSetListSiebelProvABCSImpl receives the SyncSpecificationValueSetList EBM message as input. SyncSpecificationValueSetListSiebelProvABCSImpl transforms the SyncSpecificationValueSetList EBM message into a Siebel request ABM message and calls the synchronize attribute definition Siebel Web service.

This service also filters the MLS mapping. A filter condition uses DVM to get the details on how many languages a provider system is supporting. Only those languages are synchronized to the provider system, for example, Siebel.

Synchronize attribute definition Siebel Web service returns the response to SyncSpecificationValueSetListSiebelProvABCSImpl service, which has the status details.

SyncSpecificationValueSetListSiebelProvABCSImpl

SyncSpecificationValueSetListSiebelProvABCSImpl receives the response from synchronize attribute definition Siebel Web service and transforms the Siebel response ABM message into SyncSpecificationValueSetListResponseEBM and calls the SpecificationValueSetResponseEBS service.

The valueset synchronization is based on all or none basis. If OPH is sending a batch of 10 valuesets out of which five fail, this status is sent back to OPH that batch failed and the error that comes from the provider service is logged in error-handling framework.

SpecificationValueSetResponseEBS

SpecificationValueSetResponseEBS routes the SyncSpecificationValueSetListResponseEBM to SyncSpecificationValueSetListPIMReqABCSImpl

SyncSpecificationValueSetListPIMReqABCSImpl

SyncSpecificationValueSetListPIMReqABCSImpl service transforms the SyncSpecificationValueSetListResponseEBM message into a OPH valueset status-update Web-service input message and calls the OPH value set status-update Web service.

OPH value set status update Web service

This Web service takes the input message from the SyncSpecificationValueSetListPIMReqABCSImpl service and updates the status in OPH as:

Success

Failed


3.1.14 Batch and Initial Load

The integration does not support initial load or batch load capability for item catalog categories. The recommended process is to publish the ICCs one at time because this is performed design time.

3.1.15 Multi Language Support for Valueset Synchronization

See Section 2.3.2, "Support for Multi-Language for Item Synchronization"

3.1.16 Synchronization of Products, Discounts, and Associated Structures from Oracle Product Hub to Siebel CRM

Products and discounts are created as items in Oracle Product Hub and are synchronized to one or more Siebel CRM instances. The items and BOMs together with the seeded telecommunications library attributes are used to model various entities like products, discounts, bundles, promotions in Oracle Product Hub.

For more information on modeling the entities in Oracle Product Hub, see the whitepaper "Guidelines and Methodology to Define and Manage entities in Oracle Product Hub for Oracle Product MDM Integration 2.5" Note ID - 1086492.1 on My Oracle Support.

For more information about the functional and technical details of this process flow, see Chapter 2, "Synchronization of Items and BOMs".

3.1.17 Multi-Event Product Synchronization from OPH to Siebel

Products that have multiple charges and events are created as customizable products in Siebel. Events are created as separate products and are added as child products of the main product. The component products represent the charges and events and have the billing type of event that is set in Siebel. The item synchronization process from horizontal implementation supports both create and update of products in Siebel.

To support create and update of pricelist, the process integration to Siebel reuses the communications pricelist Siebel-provider-connector services. The OPH requestor item ABCS must create the corresponding item and pricelist line cross-references.

3.1.18 Support for Class Type Relationship in Product Synchronization for Siebel CRM

The item definition in OPH (for product) supports two types of parent-child relationships:

  • Relationship of domain type as product: The product relationship represents another item that is related to the root item.

  • Relationship of domain type as class: The class relationship provides a list of items that can be treated as options. In OPH, these items are defined as a BOM with BOM item type as option class. The options are added as components of the BOM. During the promotion definitions, the item that has a class relationship is reused across promotions and one or more items in the options are included or excluded based on the promotion modeling.

Note:

Domain type is a UDA associated with the item that identifies the type of relationship.

For more information about Telco seeded library attributes and their corresponding valuesets, see "Seeded Item Metadata Libraries," Oracle Product Hub Implementation Guide.

Table 3-7 provides an example of how product and class type relationships are supported in OPH and how the process integration creates them in Siebel.

Root item (item with a model type of BOM)

Wireless router (item)

Bluetooth devices (item with an option class type of BOM and entity type of option group)

Samba Bluetooth Headset

B-Micro Bluetooth Headset

Table 3-7 Example of how product and class type relationships are supported in OPH

Item Catalog Category Item Item Components

Wireless Router Class

Wireless Router

NA

Wireless Device Accessory

Bluetooth devices

NA

Wireless Device Accessory

NA

Samba Bluetooth Headset

Wireless Device Accessory

NA

B-Micro Bluetooth Headset


Table 3-8 depicts the OPH definition of the relationship in the seeded attribute group: version structure associated with the root item. These attributes are component attributes for which values are set in context of the root item.

The type is expected to be set to Option Group. If the type is not set to Option Group, the class relationship is not set in Siebel; instead, it is associated as a product.

Table 3-8 OPH definitions

Relationship Name Domain Type Product Class Default Cardinality

Relationship1

Product

Wireless Router

NA

1

Relationship2

Class

Bluetooth devices

Wireless device accessory

1


For product relationship, the process integration creates a relationship of type product in Siebel for the root item. This relationship has an empty relationship domain in Siebel.

For class relationship, the process integration creates a relationship of type class and adds all the components of the Bluetooth devices as the relationship domain. The product (Bluetooth devices) is not included as a part of the relationship in Siebel.

Table 3-9 provides an example of the support for relationship for products in Siebel.

Root Item

Relationship1 = Wireless Router

Relationship2 = Wireless Device Accessory

Samba Bluetooth Headset

B-Micro Bluetooth Headset

The structure attributes of the root item in Siebel are:

Table 3-9 Attributes for root items in Siebel

Relationship Name Domain Type Product Class Default Cardinality

Relationship1

Product

Wireless Router

NA

1

Relationship 2

Class

NA

Wireless device accessory

1


Table 3-10 Relationship domain

Relationship Domain Quantity

Samba Bluetooth Headset

X

B-Micro Bluetooth Headset

X


To update the relationship domain, you can add more product components to the product Bluetooth devices and all the items that have a class relationship with Bluetooth devices must be synchronized to Siebel for the relationship domain to be updated. Updating the Bluetooth devices and synchronizing them is a prerequisite.

Siebel has a relationship type attribute called domain type, and a DVM is created to map the domain type.

Any change in the relationship creates a new version of root item in OPH. The process integration updates the corresponding root item and the relationship in Siebel CRM.

Note:

A BOM item with the same item catalog category or a simple item cannot be added as a component of any root item more than once for any parent-child relationship in OPH.

3.1.19 Support for Controlling Auto-Release of Entities Published from Oracle Product Hub in the Same Batch for Siebel

The Product MDM integration enables the product administrator to control the automatic release of all the entities within the project workspace in Siebel at a more granular level than the Siebel system parameter. This enables different behaviors with regard to entity auto-release based on the publishing style and the needs of the various product administrators.

OPH passes a flag to allow a more granular control at the batch level for the release of all the entities within the project workspace. This flag specifies whether the entities within the project workspace should be auto-released, should not be auto-released, or should use the default behavior set in Siebel with regard to auto-release.

  • While OPH sets the flag at the batch level, Siebel cannot use it at the batch level because within a batch, multiple Siebel services are called for product and discounts, price list items, promotions, and structures. If the flag is set at service invocation level, inconsistencies may exist, for example, the service for product and discounts may succeed and all the product and discounts released in Siebel, but the service for the associated structures may fail and the overall batch publishing would fail; however, the entities for product and discounts are released in Siebel. Hence, the workspace cannot be released until all the entities in the batch that need to be synchronized are successfully synchronized.

  • OPH also passes a workspace name. The Siebel ABCS uses the workspace name received from OPH as the product workspace name. The workspace name allows creating all the entities from the same batch within the same workspace.

  • OPH passes the batch auto-release flag and workspace name with each payload (item payload and BOM payload) at the header level. Values of these parameters are consistent in different payloads associated with the same batch ID.

  • The batch auto-release flag is set to one of these values:

    • Y - indicates that the batch is released automatically

    • N - indicates that the batch is released manually

    • D - indicates that the release of the batch should be controlled by the Siebel system parameter. This is the default.

    OPH always publishes the batch auto-release flag with a value of D.

  • Siebel services for the creation of product and discounts, promotions, price list items, and structure take these at the header level:

    • Workspace name

    • Workspace reuse flag

    • Auto-release flag

    If a workspace does not exist, Siebel creates a new workspace; however, if it exists, the workspace reuse flag is set to Y and the workspace is reused. Otherwise, if the workspace exists and the workspace reuse flag is set to N, a new workspace is created the name of which is a concatenation of the value in the workspace name and a time stamp.

  • When the first Siebel service within a batch is invoked, which typically is the service for the creation of products and discounts:

    • The value passed from OPH in the workspace name is used for the Siebel workspace name.

    • The value passed in the batch auto-release flag is used for the Siebel auto-release flag (upon DVM conversion), and the Siebel workspace reuse flag is set to N.

  • When subsequent Siebel services are invoked for the same batch:

    • The value passed in the batch name is used for the Siebel workspace name.

    • The value passed in the batch auto-release flag is used for the Siebel auto-release flag (upon DVM conversion), and the Siebel workspace reuse flag is set to Y.

  • Finally, when all the Siebel services pertinent to the same batch have been invoked and if the batch has succeeded, one more service for the creation of product and discounts is invoked with an empty sequence of products and discounts. It has these values for the header attributes:

    • The workspace name is the value passed in the batch name.

    • The Workspace reuse flag is Y.

    • The Auto-release flag is Y.

  • Within Siebel, an unpublished workspace is not discarded, because administrators may want to access them for investigation. Periodic cleansing of unpublished workspaces is an administrator activity in Siebel.

Note:

The auto-release flag is always passed as Default from OPH.

3.1.20 Synchronization of Promotions from Product Hub to Siebel CRM

Promotions are defined as items in OPH with entity type as promotion. The process integration creates product promotions for every such item in Siebel.

Promotions have model BOM as the structure. The model BOM can have one or more items that have model BOMs as structure or can have items that represent promotion level discounts. The process integration adds the corresponding customizable products as components of the promotions in Siebel.

  • Promotions cannot have an option class BOM associated with the root item. The immediate components of the promotion can have a BOM of type option class. The items or components that are associated with BOMs of type option class are reused to create different promotions.

  • Promotions support n-level nesting of BOMs. The typical value for n is between 1 (one) and 6 (six).

  • In addition to the seeded UDA that is set for the item, these seeded user-defined attributes (UDAs) that are specific to items of entity type promotions are set during the promotion definition in OPH. See Sellable Product Information Library under Telco Seeded Library Attributes for more information.

    • Promotion: More Information

    • Charge Plan: Non Recurring Charge Details

    • Charge Plan: Recurring Charge Details

    • Charge Plan: Charges, Adjustment, Usage Plan Details

    • Commitment: Charges Credits

    • Product Promotions: Upgrade

  • The process integration to Siebel sets the corresponding fields of the promotion in Siebel.

  • Whenever a BOM is created for the promotion (root item) and the components are added, these seeded component UDAs are set during the promotion definition in OPH. See Component UDA for Item Synchronization under Telco Seeded Library Attributes.

    • Product Promotions: Components (Component UDA)

    • Product Promotions: Component Pricing (Component UDA)

    • Product Promotions: Pricing: Components: Adjustments (Component UDA)

  • Once the promotions and all the associated BOMs and their components are successfully synchronized to Siebel, the status is updated in OPH publication history. Even if one of the components or child components of the BOM within the promotion fails, or is partially successful, the status on the promotion item is failed.

  • Adding, deleting, or updating the components that are directly associated with the promotions, or updating the fields of promotions such as promotion name, description, and so on, or updating the promotion-related information such as seeded and component UDA creates a new revision of the promotion in OPH. The new revision must be published to the downstream applications from the publication framework in OPH. For the deletion of components, the expectation is that the AIA configuration property synchronization flag be set to Y.

Component Exclusions in Context of Promotions

Whenever a promotion is defined in OPH, some of the components of the promotion or subcomponents under the root item can be excluded.

In Figure 3-5 the components that are marked in red are excluded in context of the promotion A. In addition, item E with the associated BOM has been reused in the promotion definition under a different component B. These signify different paths to the components under the same root item (promotion) definition.

Figure 3-5 An example of component exclusions

Component exclusions

OPH publishes the entire promotion definition with all the components, and wherever exclusions exist, it explicitly marks the exclusions by providing the path of exclusion from the root item (promotion).

The process integration to Siebel handles the exclusions as follows:

  • Siebel provides a contextual framework to control the promotion definition. In Siebel, the complete promotion definition with components at all levels can be updated in context of the promotion without affecting the original definition of the customizable products that are included in the promotion definition. The integration identifies the components that are excluded, which is specified in the payload that is published from OPH. Siebel does not remove or delete the components of customizable products in context of the promotions. This is a documented Siebel limitation.

The process integration uses the cardinality associated with the components to exclude the components in context of the promotion.

The promotion definition in OPH can specify the exclusions in these ways:

  • Promotion definition can set the minimum cardinality and maximum cardinality of the component UDA to be 0 (zero).

  • Promotion definition can mark the exclusions of the components.

Note:

Siebel provides the context-specific framework only in case of product promotions, not for customizable or component-type customizable products.

Exclusions Within Option Class BOMs

Table 3-11 explains the exclusions within option class BOMs.

Table 3-11 Exclusions within option class BOMs

1

VoIP Limited Package

1.1

VoIP Core Bundle

1.1.1

VoIP Core Service

1.1.1.1

VoIP Service Options

1.1.1.1.1

Basic VoIP

1.1.1.1.2

VoIP w/ unlimited calls

1.1.1.1.3

Fast Dialing

1.1.1.2

VoIP Voicemail

1.1.1.3

VoIP Caller ID

1.1.1.4

VoIP Fax Service

1.1.2

VoIP Adaptor

1.1.3

VoIP Phone

1.1.4

VoIP Laptop Phone

1.2

VoIP Recurring Discount


Case 1: Exclude components of item that represents promotions

The component items that are directly under the promotion are excluded by removal of the components.

These are the immediate components of the promotion VoIP Limited Package

  1. VoIP Core Bundle

  2. VoIP Recurring Discount

If any of these components have to be excluded, both the minimum and the maximum cardinality in the component UDA - Product Promotions: Components must be set to 0 (zero) in OPH and synchronized to Siebel CRM.

Case 2: Exclude components of items that represent bundles within the promotion

The component items that are not immediate children of the promotions but are subcomponents in the promotion definition are excluded by specifying the minimum and maximum cardinality as 0 (zero).

These are the subcomponents of the promotion VoIP Limited Package:

  1. VoIP Core Service

  2. VoIP Service Options

  3. VoIP Voicemail

  4. VoIP Caller ID

  5. VoIP Fax Service

  6. VoIP Adapter

  7. VoIP Phone

  8. VoIP Laptop Phone

If any of these components are to be excluded, both the minimum and the maximum cardinality in the component UDA - Version: Structure must be set as 0 (zero) in OPH and synchronized to CRM.

Case 3: Exclude component of option class items

The components under an option class item have to be excluded in OPH by means of the exclusion method provided in the product workbench. Default cardinality in the component UDA - Version: Structure must be specified in OPH for all the items that are not excluded.

These are the components of the option class item VoIP Service Options:

  1. Basic VoIP

  2. VoIP with unlimited calls

  3. Fast Dialing

If the VoIP with unlimited calls and fast dialing needs to be excluded, exclude these from the OPH product workbench and specify the override value for default cardinality of Basic VoIP.

If one of the components of the option class has to be made optional in context of the promotion, the default cardinality must override to 0 (zero).

Note:

If a component has to be excluded from the option class, the default cardinality of the included items must be overridden with a value in the context of the item that represents a promotion.

If the VoIP with unlimited calls needs to be excluded and fast dialing made optional, exclude the VoIP with unlimited calls from the OPH product workbench, specify the override value for default cardinality of Basic VoIP, and override the default cardinality of fast dialing to 0 (zero).

Note:

If an override is not specified to any of the components, none of the components are excluded and the default quantity in the target application is set to 0 (zero), thus making all the components available as optional items as part of the same promotion.

Component Overrides in Context of Promotions

  • The promotions contain various levels of BOMs, where the model BOM is the root BOM. The components association with the BOMs within the context of the promotion can be overridden. For example, the minimum cardinality set at the immediate parent item can be overridden in context of the promotion.

  • This UDA is used to update the component association at every level of the BOM: Version: Structure (Component UDA).

  • The process integration sets the component overrides in context of promotions in Siebel.

Transaction Attribute Value Exclusions in the Context of Promotions

  • A valueset is associated with every transaction attribute of the item. In OPH, a subset of values from the set of values of the valueset can be excluded for the transaction attribute of a component in context of the promotion. The metadata synchronization process synchronizes all the valuesets from OPH to Siebel. See Section 3.1.1, "Synchronization of Metadata".

  • Whenever the items are added as components of the BOMs of parent items or added as components of BOMs that are included in the promotions, the product administrator in OPH can exclude a subset of values from the valueset associated with the transaction attribute in context of the BOM or the root item. During promotion synchronization to Siebel, OPH provides the values that were excluded from the valueset. The component that is marked in green represents the excluded value. This is marked C in the diagram depicting components exclusion.

  • The process integration to Siebel must set the values as exclusions for the corresponding attributes published from OPH in context of the promotion.

Promotion Based Discounts

The discounts on the components of the promotion are specified by means of these component UDAs:

  • Product Promotions: Component Pricing (Component UDA)

  • Product Promotions: Pricing: Components: Adjustments (Component UDA)

For more information about how to define promotion-based discounts in Oracle Product Hub, see the whitepaper "Guidelines and Methodology to Define and Manage Entities in Oracle Product Hub for Oracle Product MDM Integration" in article ID 1086492.1 on My Oracle Support.

3.2 Siebel CRM Interfaces

Siebel CRM interfaces used by the integration are:

Inbound Siebel CRM Web Services: Synchronize Items or BOMs

Inbound Siebel CRM Web Services: Synchronize Pricelist

Inbound Siebel CRM Web Services: Synchronize Promotions

Inbound Siebel CRM Web Services: Synchronize Attribute Definition

Inbound Siebel CRM Web Services: Synchronize Product Class

Outbound Siebel CRM Web Services

There are no outbound events from Siebel CRM for the Oracle Product Hub integration.

For more information about Siebel web services, see CRM Web Services Reference.

3.3 Siebel CRM Integration Services

These are the integration services required for Siebel CRM to integrate with Oracle Product Hub:

3.3.1 SyncProductSiebelProvABCSImpl

This single operation service accepts a SyncItemListEBM product message as a request. It does the following on receiving the ItemEBM based on the entity type specified with the item:

For type promotion, it transforms this message into a Siebel promotion ABM and invokes the Siebel promotion ABM. For the type as product or discount, it is assumed to be of type product.

For type as option_group it is assumed as Option Group. For discount_model it is assumed as Discount Model and for bundle it is assumed as Commercial Bundle. In case of non-promotion items-based on the entity type, the transformation conditionally transforms the corresponding elements required to support that entity.

This service transforms the message into Siebel product ABM. It invokes the Siebel product web service to synchronize with Siebel.

3.3.2 SyncBillOfMaterialsListSiebelProvABCSImpl

This single operation service accepts a SyncBillOfMaterialsListEBM product message as a request and returns SyncBillOfMaterialsListResponseEBM message. The BillOfMaterialsEBS invokes SyncBillOfMaterialsListSiebelProvABCSImpl.

This service receives SyncBillOfMaterialsListEBM, transforms it into a Siebel product ABM, and invokes the Siebel product web service to synchronize the item structure with Siebel.

When an item is defined as an option class in OPH, the provider services has two distinct behaviors:

  • Synchronize option class as a product with the option components as relationships with domain type of components.

  • Option class item can be established as a child with domain type of class. The service to establish the same as class is based on the values set for the component UDAs associated with the product. Domain type must be set to class, and the relationship name and class name must be same as ICC name that is pre-established in Siebel as product class.

  • The components under the option class item in OPH are set as relationship domain for the class type relationship.

3.3.3 SyncClassificationSchemeListSiebelProvABCSImpl

This single operation service accepts a SyncClassificationListEBM product message as a request.

The responsibility of this service is to receive SyncClassificationListEBM, transform it to Siebel product class ABM, and invoke the Siebel product-class web service to synchronize it into Siebel. Once the product class synchronization is done in Siebel, it passes the response message to ClassificationResponseEBS.

3.3.4 SyncSpecificationValueSetListSiebelProvABCSImpl

This single operation service accepts a SyncSpecificationValueSetListEBM product message as a request.

The responsibility of this service is to receive SyncSpecificationValueSetListEBM, transform it to Siebel attribute definition ABM, and invoke the Siebel attribute-definition web service to synchronize it into Siebel. Once the attribute synchronization is done in Siebel, it passes the response message to specification valueset response EBS.

3.3.5 ProductOptimizedSyncPriceListListSiebelCommsProvABCSImpl

The ProductOptimizedSyncPriceListListSiebelCommsProvABCSImpl service transforms the PriceList EBM into a Siebel price list message and then calls the Siebel pricelist web service on operation InsertOrUpdate. The ProductOptimizedSyncPriceListListSiebelCommsProvABCSImpl transforms the PriceList EBM into a Siebel product message and then calls the Siebel product web service on operation Product_spcImport_spcUpdate. The Siebel web service completes the request and returns a response message. ProductOptimizedSyncPriceListListSiebelCommsProvABCSImpl then transforms the Siebel response message into the PriceList response EBM and sends it back to PriceListEBS.

Figure 3-6 ProductOptimizedSyncPriceListListSiebelCommsProvABCSImpl

ProductOptimizedSyncPriceListLineListSiebelProvABCSImp

3.3.6 SyncItemCompositionListSiebelCommsProvABCSImpl

The SyncItemCompositionListSiebelCommsProvABCSImpl process accepts the SyncItemCompositionListEBM. It transforms SyncItemCompositionListEBM into the Siebel product ABM. It then invokes the Siebel Product web service to create products and product structures in Siebel.

Figure 3-7 SyncItemCompositionListSiebelCommsProvABCSImpl

SyncItemCompositionListSiebelCommsProvABCSImp

3.4 Assumptions and Constraints for the Siebel CRM Option

The assumptions and constraints for the Siebel CRM option are:

  1. The Item with BOM item type = "Option Class" and its component items must have the same item catalog category.

  2. Changes to the seeded static attribute groups are not supported. If customers want to introduce new static attributes, they must define new attribute groups and static attributes. The integration creates these as flex attributes in Siebel. If new valuesets are introduced in OPH for new UDA, the integration passes the information as free-form text.

  3. The items and BOMs in the structure of an ICC must be published before the ICC is published.

  4. The item catalog categories that are associated with the items must be synchronized to Siebel before the items are published.

  5. Every operating unit in Oracle Product Hub that has an associated order-entry item-validation organization needs to be defined as a business unit in Siebel and the item validation organization defined as the inventory location associated with the business unit in Siebel. This is required even if the operating unit and inventory organization role is associated with the same organization. For more information about establishing cross-references, see Section 6.4, "Setting Up Cross-References". (This is applicable only if the Order to Cash: Siebel CRM - EBS integration is being planned or implemented with Product MDM.)

  6. The cross-references for inventory organization for item validation organization are set only for Siebel CRM and only those items from an item validation group that are associated with a single operating unit can be synchronized to Siebel CRM. (This is applicable only if the Order to Cash: Siebel CRM - EBS integration is being planned or implemented with Product MDM.)

  7. Oracle Product Hub produces multiple BOM revisions, but it can identify whether the component item of the BOM is part of the current revision or a future revision of the BOM so that Siebel can filter out the item components that are not part of the current BOM structure. Siebel has a limitation that it uses only the current BOM revision.

  8. The integration does not support multi-tier pricing between OPH and Siebel.

  9. For Siebel CRM, these entities and associated subcomponents need to be locally enriched:

    • Eligibility rules.

    • Proration plans for items of entity type of promotion.

    • Compatibility rule matrix.

    • Matrix discounts.

    • Volume discounts.

    • Attribute adjustments.

  10. Once the products are successfully synchronized from OPH to Siebel, they can also be updated to enrich the product definition.The existing products (subscription) that have references to pending quotes, orders, or assets in Siebel or Oracle BRM cannot be enabled as simple-service bundles. Similarly, the simple service bundles cannot be changed into subscription based billing products because by doing this, it impacts the existing asset cross-references. This is enforced by using the Siebel validation only in the UI.

    A mechanism or methodology must be defined for a product administrator in OPH to identify a given set of products that have pending quotes, orders, or assets in Siebel (Order capture application). Once identified, the corresponding products must not be updated and synchronized to Siebel unless the validation is added in the Siebel application.