Vendor master data is essential to the procurement and accounting functions within a company. A typical purchasing business process begins with the creation of Purchase Requisitions which are then sent through a Materials Resource Planning (MRP) run. Vendors are selected for the purchase requisitions, which are next consolidated into Purchase Orders (POs). After these are approved, they are sent to the vendor for fulfillment.
Vendors are referenced on Purchase Orders as the legal entity that represents the "Supplier" entity. Vendors, like customers, have partner functions or roles that they fulfill themselves or for other vendors. Vendors can function as:
The VendorSync collaboration template, in conjunction with the other collaborations that compose the Vendor Manager collaboration-object group, specifies a common process for maintaining and synchronizing vendor information. This process enables a common view of vendor information throughout the organization by assuring the accuracy of duplicate information in both the source and destination applications without duplicate entry.
The Vendor Manager collaboration-object group synchronizes vendor information between a Customer Interaction Management (CIM) application and an Enterprise Resource Planning (ERP) application. Either of these types of applications can serve as the source of or destination for the synchronized information.
Vendor information is often stored in a hierarchy with the primary Vendor, which is referenced in Requisition Processing, at the top. Supporting vendor information, such as Invoicing and Supplier data, is stored in relationship to the primary Vendor.
IBM WebSphere Business Integration Server Express Plus stores data about the primary Vendor in the generic Vendor business object. It stores data about related Vendors or addresses in the generic VendorPartner business object. IBM WebSphere Business Integration Server Express Plus also uses the Vendor business object to store the relationships between the primary Vendor and its related Vendors.
The Vendor Manager collaboration-object group uses these two generic business objects and three collaborations to synchronize primary Vendors and their related data. The three collaborations are:
VendorSync uses the generic Vendor business object to synchronize a primary Vendor and its relationships to related Vendors. The collaboration can be configured (VERIFY_SYNC_VENDORPARTNERS) to cause the synchronization or verification of all vendor data related to the primary Vendor. If so configured, VendorSync creates a generic VendorPartner business object for each related Vendor or address and sends it to the VendorPartnerWrapper collaboration. The value of the VERIFY_SYNC_VENDORPARTNERS property determines whether VendorSync sends VendorPartner with the Sync or Exists verb, which specifies either synchronization or verification.
Another of VendorSync's configuration properties (SYNC_PARENT_FIRST) determines whether the collaboration synchronizes the related Vendor before or after it synchronizes the primary Vendor. The choice depends on how the destination application stores the data. The two storage options are:
Some applications (such as Baan and Vantive) store the relationship at the child level (that is, in the VendorPartner role). The VendorPartner data does not exist independently of its parent primary record and cannot be associated with more than one primary Vendor. The primary Vendor must exist before these related records can be created.
For example, when VendorSync is bound to Oracle as the destination application, configuring SYNC_PARENT_FIRST to "true" causes the collaboration to:
Notes: Because IBM WebSphere Business Integration Server Express Plus stores the link to the child in the parent (generic Vendor) business object:
Some applications (such as Clarify, PeopleSoft, and SAP) store the relationships between the primary Vendor and its related Vendors at the parent level. These applications store the Vendor's related VendorPartner data (such as Invoicing Vendor and Supplier Vendor) as separate objects. These objects exist independently of their parent primary Vendor business object and can be associated with more than one primary Vendor. These related VendorPartners must exist before the primary Vendor is created.
For example, when VendorSync is bound to SAP as the destination application, configuring SYNC_PARENT_FIRST to "false" causes the collaboration to:
Note: In IBM WebSphere Business Integration Server Express Plus, a primary Vendor cannot serve as a VendorPartner for another primary Vendor. Therefore, even applications that allow this relationship might require customization to represent a primary Vendor as the Invoicing VendorPartner for another primary Vendor.
For information about all of VendorSync's configuration properties, see Configuration properties.
VendorPartnerSync synchronizes VendorPartners in the destination application. VendorPartnerSync can be run independently of VendorSync, in which case it is triggered directly by a source application. If triggered by VendorSync, VendorPartnerSync returns a status to it.
For information on VendorPartnerSync's configuration options, see the Checklist for setting configuration properties.
VendorPartnerWrapper either verifies the existence of related vendor data in the destination application or causes the data to be synchronized in the destination.
In either case, VendorPartnerWrapper returns a status to its calling collaboration.
For information on VendorPartnerWrapper's configuration options, see the Checklist for setting configuration properties.
Running the Vendor Manager collaboration-object group might require configuring and running several different collaboration objects. Assume, for example, that you configure VendorSync to synchronize related vendor data, as well as primary Vendor data. Assume, also, that your installation synchronizes related vendor data independently of primary Vendors.
Your installation requires the following collaboration objects:
Collaboration object | Description |
---|---|
VendorSync | The source application triggers a synchronize-Vendor event that is processed by a VendorSync collaboration object. VendorSync gets the unique key of each related vendor partner from the Vendor business object. The collaboration creates a reference-valued VendorPartner business object for each related vendor partner (populated only with the unique key). VendorSync then calls a VendorPartnerWrapper collaboration object to synchronize this VendorPartner in the destination application. |
VendorPartnerWrapper | Called by VendorSync, VendorPartnerWrapper retrieves the full VendorPartner business object from the source application and sends it with the Create verb to a VendorPartnerSync collaboration object. |
VendorPartnerSync | Called by VendorPartnerWrapper (to which its From port is bound), VendorPartnerSync synchronizes the VendorPartner in the destination application. |
VendorPartnerSync | The source application triggers a synchronize-VendorPartner event that is processed by a second VendorPartnerSync collaboration object. This collaboration object's From port is bound directly to the source application. The collaboration synchronizes VendorPartners independently of their related primary Vendors. |
Figure 1 illustrates the collaborations and generic business objects required in the scenario described above. The three-dimensional objects represent business objects. The ovals represent collaboration objects.
Figure 1. Relationship of required collaborations in the usage example
Note: To specify your own requirements and conditions, you must separately configure each collaboration object in the group. For more information, see Checklist for setting configuration properties.
This section includes information on port bindings and required steps for setting up collaboration objects based on VendorSync. For information on standard features, ports, and configuration properties for collaboration templates, refer to the Collaboration Development Guide. For general information on creating collaboration objects refer to the System Implementation Guide.
Figure 2 illustrates VendorSync's ports, as they are displayed in System Manager. The tables that follow provide information about each port.
Figure 2. VendorSync collaboration ports
Note: To prevent the collaboration object from using a port, bind that port to the Port connector. Binding the port indicates that the port is unused without causing the collaboration object to provide additional functionality.
Business object | Bound to | Function | Verbs used |
---|---|---|---|
Vendor | The destination application's connector | Sends a reference-valued business object to retrieve the full-valued business object. The result determines what verb to use when synchronizing the vendor |
Retrieve |
Business object | Bound to | Function | Verbs used |
---|---|---|---|
Vendor | Source application's connector or calling collaboration | Receives the triggering business object. At the end of a synchronous call, this port also returns the triggering business object to the source application when the collaboration ends successfully. |
Create Retrieve Update Delete |
Business object | Bound to | Function | Verbs used |
---|---|---|---|
Vendor | The destination application's connector |
Sends the triggering business object out of the collaboration. Note: Although this collaboration is designed to support only the Create and Update verbs, it has the standard Delete verb. Before triggering the Vendor business object with the Delete verb, verify that the destination application can handle a Vendor. |
Delete. Create Update Delete |
Business object | Bound to | Function | Verbs used |
---|---|---|---|
VendorPartner |
|
Used to send a reference-valued VendorPartner business object to the VendorPartnerWrapper collaboration
|
Sync Exists |
To set up VendorSync as a stand-alone collaboration object, follow these steps:
To verify or synchronize related VendorPartners as part of the VendorSync process, create any combination of the following collaboration-object groups:
Verify Synchronize Required collaborations VendorPartners VendorSync, VendorPartnerWrapper VendorPartners VendorSync, VendorPartnerWrapper, VendorPartnerSync
The following steps describe the setup procedure, providing alternate steps for handling VendorPartner verification or synchronization:
Note: System Manager will have already bound the VendorPartnerWrapper collaboration object's To port to VendorPartnerSync's From port. For Vendor partner verification, move directly to step #8.
This section illustrates the process logic for this collaboration template:
Figure 3 illustrates VendorSync's process logic.
Figure 3. VendorSync collaboration process logic
This collaboration template uses the following standard collaboration business processes:
For information on these processes, see the Collaboration Development Guide.
Figure 4 illustrates VendorSync's Create and Update process.
Figure 4. VendorSync collaboration create and update processes
Note: VendorSync uses VendorPartnerWrapper to send the VendorPartner business object to VendorPartnerSync. Wrapper collaborations always send the business object with the Create verb. To cause VendorPartnerSync to convert the Create to an Update when the business object already exists in the destination application, set its CONVERT_CREATE property to "true".
When VendorSync sends the Vendor business object with the Update verb to the destination, the synchronization updates relationships to VendorPartners, but it does not actually create, update, or delete a VendorPartner.
For example, when a Vendor deletes a reference to a VendorPartner, the application does not delete the VendorPartner (neither physical nor logical delete). The application simply removes the reference to the VendorPartner; it removes the relationship to the VendorPartner without removing the VendorPartner.
Figure 5 illustrates data for Vendor #100 that has been synchronized by VendorSync. Both the source and destination applications contain the same primary vendor with the same three related VendorPartners.
Figure 5. Vendor data before deletion of references to VendorPartners
Figure 6 illustrates the same primary Vendor after the source application has deleted one of its related VendorPartners. The deletion of the child business object triggers the source connector to send the Vendor business object with the Update verb to VendorSync. The graphic illustrates the state of the Vendor business object as VendorSync sends it to the destination application, before the destination application has removed the reference to the related VendorPartner.
Figure 6. Vendor data after the source application has deleted references to Vendor Partners
Figure 7 illustrates the state of the Vendor business object after deletion of the reference to the related VendorPartner in the destination application.
Figure 7. Vendor data after synchronization in the destination application
InterChange Server Express can roll back a transaction when any step in a transactional collaboration fails. For example, when VendorSync is a member of a collaboration-object group that participates in a transactional collaboration, its actions are one subtransactional step in a larger transaction. If any step in the collaboration-object group's business process fails, the transactional collaboration details how InterChange Server Express rolls back the processing of every collaboration in the group.
When a VendorSync collaboration object is used independently of other collaboration objects or the collaboration object's From port is bound to a source application rather than to another collaboration, its process comprises a single transactional step. In such a situation, it is not necessary to perform rollback.
To cause a collaboration object or a collaboration-object group to perform rollback requires modification of the collaboration template. To understand transaction processing in the IBM WebSphere Business Integration Server Express Plus system, see the System Implementation Guide. For information on adding transaction processing to the collaboration template, see the Collaboration Development Guide.
To extend the collaboration object to handle transaction processing, complete the following steps:
This section Contains the following items:
Because the Vendor Manager collaboration-object group represents three collaborations, configuring all collaborations is critical to achieve the desired behavior. The following checklist specifies the configuration properties for all three collaborations.
Goal | Property | Setting |
---|---|---|
Retrieve a Vendor from the destination application before attempting to synchronize it | USE_RETRIEVE | "true" |
Create the primary Vendor in the destination application before creating the related Vendors or addresses | SYNC_PARENT_FIRST | "true" |
Verify Vendors or addresses related to the triggering primary Vendor | VERIFY_SYNC_VENDORPARTNERS | "verify" |
Synchronize Vendors or addresses related to the triggering primary Vendor | VERIFY_SYNC_VENDORPARTNERS | "sync" |
Convert a Create request to an Update request if VendorSync's triggering business object exists in the destination | CONVERT_CREATE | "true" |
Convert an Update request to a Create request if VendorSync's triggering business object does not exist in the destination | CONVERT_UPDATE | "true" |
Goal | Property | Setting |
---|---|---|
Retrieve a VendorPartner from the destination application before attempting to synchronize it. | USE_RETRIEVE | "true" |
Convert a Create request to an Update request if VendorPartnerSync's triggering business object exists in the destination. | CONVERT_CREATE | "true" |
Convert an Update request to a Create request if VendorPartnerSync's triggering business object does not exist in the destination. | CONVERT_UPDATE | "true" |
Goal | Property | Setting |
---|---|---|
Specify that the VendorPartnerWrapper and VendorPartnerWrapper collaborations log a warning and return a success status to their calling collaboration if a verification or synchronization of related vendor data fails | CONTINUE_WITH_WARNING | "true" |
This section describes the standard properties and collaboration template-specific properties for this collaboration template:
This collaboration template uses the following standard configuration properties for collaboration templates:
For information on these configuration properties, see the Collaboration Development Guide.
In addition to its standard configuration properties, this collaboration template has the configuration properties described below.
Property name and explanation | Possible values | Default value |
---|---|---|
SYNC_PARENT_FIRST Set to "true" to cause VendorSync to create the primary Vendor (parent business object) in the destination application before it creates the related vendors or addresses (VendorPartners). Use this setting when the destination application does not reuse the vendor partner, that is, the application stores the parent/child relationship in the child. In this case, the application must create the Vendor before it can create any of the VendorPartner business objects. Set to "false" to cause VendorSync to create the related vendors or addresses (VendorPartners) in the destination application before it creates the primary Vendor (parent business object). Use this setting when the destination application reuses the vendor partner, that is, the application stores the parent/child relationship in the parent. In this case, the application must create the VendorPartners before it can create the Vendor business object. |
true, false | false |
VERIFY_SYNC_VENDORPARTNERS Set to "neither" to cause this collaboration to synchronize its triggering business object without first synchronizing or verifying related VendorPartners in the destination application. Set to "sync" to cause this collaboration to synchronize supporting vendor information that is stored in relationship to the primary vendor. The collaboration performs the following process:
Set to "verify" to cause this collaboration to verify the related VendorPartner in the destination application. The collaboration performs the following process:
Note: For descriptions of the messages for VendorSync, refer to the collaboration message file: \collaborations\messages\VendorSync.txt |
sync, verify, neither |
neither |
To view an explanation of the messages of this collaboration template, launch the Log Viewer and open the collaboration template's message file. To launch the Log Viewer and open the collaboration template's message file:
To upgrade to a newer version of the collaboration template, perform the following steps: