Siebel Partner Relationship Management Administration Guide > Setting Up Application Services Interfaces > ASI Workflows >

Shopping Cart Transfer Workflows

The workflow processes described in this section are associated with shopping cart transfer.

They are used for the following functions:

• Outbound transfer
• Inbound transfer

They transfer as much data as is needed for the receiving system to be able to process the Shopping Cart. This includes sending information on the account and contact that serve as customers to the shopping cart, as well as the quote, and any of the extended attributes of products in the shopping cart, and information about the source and destination organizations.

Workflows for Outbound Shopping Cart Transfer

Outbound shopping cart transfer uses the following processes:

• Transfer Cart Outbound Initial. Manages the general process flow, from the selection of the destination organization to the acknowledgment processing.
• Transfer Cart Outbound Request. Controls the creation of the Shopping Cart Data Structure. Most of the work is done in the subprocesses; everything is pieced together here.
• Transfer Cart Outbound Create Header Process. Gathers and sets data needed for the message header and creates the message header.
• Transfer Cart Outbound Create and Append Process. Used in many places as a utility workflow process that creates the child hierarchy and appends the child instance to the parent object.
• Transfer Cart Outbound Receive Acknowledgment Process. Processes the response generated by the external system.

Many of these workflows have steps with names similar to Rename Child Object and Remove Message Layer. These steps deal with formatting the data structures correctly as they are passed up from subprocesses, and they are not associated with any business logic.

Workflows for Inbound Shopping Cart Transfer

Inbound shopping cart transfer uses the following processes:

• Transfer Cart Inbound Receive. Handles the initial processing of the data.
• Transfer Cart Inbound Create Cart. Handles the task of coordinating calls to the other subprocesses. If an error occurs with either the customer contact or an account, it uses user-configurable business logic to determine what happens next.
• PRM ANI Inbound Create Account. Inserts an account record if the data is present and viable. Returns an error if the data is not viable. Skips the insert steps if the data is not present, assuming that the Customer only has Contact information, and no Account.
• Transfer Cart Inbound Create Contact. Creates the Customer Contact information if the data is present and viable. Returns an error if the data is not viable. Assumes the contact is anonymous if the data is not present.
• Transfer Cart Inbound Create Quote. Creates the Quote (persistent shopping cart) after checking the data for integrity.
• PRM ANI Inbound Addressing Change. Swaps the Source Organization and Destination Channel Partner information.

Error handling is used to catch problems and report them to the external (requesting) system. Generally, if an error is found, the process will halt and pass the error messages up to the calling process. The calling process will in turn pass the error back to its calling process. When it reaches the top process, it will return an error saying that the transfer was unsuccessful.

Transfer Cart Outbound Initial Process

The Transfer Cart Outbound Initial Process workflow process is shown in Figure 15.

Figure 15. Transfer Cart Outbound Initial Process

When this workflow is called, the following events happen:

• The first step checks for the availability of the items the customer wants to purchase.
• The next step finds the communication information associated with the partner and then runs the Transfer Cart Outbound Request Process subprocess to create the Shopping Cart data structure.
• The next step checks to see if we are in debug mode (controlled by the Debug Flag in the Process Properties). If we are, we need to dump the data into a file and read in a suitable response from a file.
• Most of the time the Debug Flag is set to false, and will allow for use of the Web Services instead. In this case, the RPC call is made and a response is received when web services is complete.
• The Response is processed by Transfer Cart Outbound Receive Acknowledgement Process (either success or failure) as the final step in this process.

Transfer Cart Outbound Request Process

The Transfer Cart Outbound Request Process workflow process is shown in Figure 16.

Figure 16. Transfer Cart Outbound Request Process

When this workflow is called, the following events happen:

• The first step creates the message header, with information about the message itself including timestamps, and so on.
• The Next step adds the shopping Cart Data (Quote, Quote Item, and so on) to the Shopping Cart data structure.
• Next, the process includes information about the Source Organization sending the data.
• Then it appends information about the destination partner to this message.
• Finally, it adds the Customer information, including account and customer data.

Transfer Cart Outbound Create Header Process

The Transfer Cart Outbound Create Header Process workflow process is shown in Figure 17.

Figure 17. Transfer Cart Outbound Create Header Process

When this workflow is called, the following events happen:

• The early steps gather and set data used in the message header.
  • They set all of the key information first, including the Internal Key and Key description. This is used by the External system to reference a record in our database.
  • They also set the timestamps and status messages.
• The later steps instantiate the header instance by creating an empty data structure based on the metadata provided by the integration object definition in Siebel Tools, and they append all the data to the empty data structure.

Transfer Cart Outbound Create and Append Process

The Transfer Cart Outbound Create and Append Process workflow process is shown in Figure 18.

Figure 18. Transfer Cart Outbound Create and Append Process

When this workflow is called, the following events happen:

• First, it creates the child hierarchy. If no business component reference is provided (empty Customer Account Data, for instance) it instantiates an empty instance of the child.
• Then it appends the child instance to the Parent Object. This is the Shopping Cart Object most of the time. If a flag is set, it can create an empty parent, and append this child to it.

Transfer Cart Outbound Receive Acknowledgment Process

The Transfer Cart Outbound Receive Acknowledgment Process workflow process is shown in Figure 19.

Figure 19. Transfer Cart Outbound Receive Acknowledgement Process

When this workflow is called, the following events happen:

• First, it gets the status of the message that has been received and looks for the partner it was received from.
• Then it looks for an existing Keymap record so that we know whether to update it or create a new record. The Keymap data holds information about transferring of information, including the time of the last transfer and the key we can use to reference the shopping cart's counterpart in the external system.
• If there is no error, it creates or updates the keymap record and retrieves the URL information. Then it renders the redirection view with the URL it has retrieved, using Virtual Fields.
• If there is an error, it presents the customer with an option view that allows the customer to decide whether to choose another partner, or cancel the transaction.

Transfer Cart Inbound Receive Process

The Transfer Cart Inbound Receive Process workflow process is shown in Figure 20.

Figure 20. Transfer Cart Inbound Receive Process

When this workflow is called, the following events happen:

• First, it makes sure that the sender is someone that is authorized to send requests.
• It checks that the external system's key is present, and that we are the intended recipients.
• It gets the key description and runs the Transfer Cart Inbound Create Cart Process.
• If an error is generated, it report it to the calling system and finishes the process. No Keymap record is created because the quote may not have been created.
• If no error is generated (OK status), it:
  • updates the keys statuses in the shopping cart message.
  • creates the Keymap record.
  • generates the URL needed to send to the calling system, so it can redirect the user to this system, with this shopping cart.
  • sets the timestamps and sends the message back the caller.

Transfer Cart Inbound Create Cart Process

The Transfer Cart Inbound Create Cart Process workflow process is shown in Figure 21.

Figure 21. Transfer Cart Inbound Create Cart Process

When this workflow is called, the following events happen:

• First, it checks of the quote.
• Then it inserts the customer account information.
• Then it inserts the customer contact information.
• Then it inserts the quote information and links it to the customer information.

PRM ANI Inbound Create Account Process

The PRM ANI Inbound Create Account Process is shown in Figure 22.

Figure 22. PRM ANI Inbound Create Account Process

When this workflow is called, the following events happen:

• It checks to see if the Account Name and DUNS Number are viable.
• It looks in the database for an account with the same DUNS number. This Number is our method of uniquely identifying an account or partner.
• If the account is found, it report the record's id.
• If the account is not found, it creates a new account.

Transfer Cart Inbound Create Contact Process

The Transfer Cart Inbound Create Contact Process workflow process is shown in Figure 23.

Figure 23. Transfer Cart Inbound Create Contact Process

When this workflow is called, the following events happen:

• It checks for the presence and viability of data. If data is not present, it assumes that the Contact is Anonymous. If the data is not viable, it returns an error.
• It creates a user key for the contact similar to the user key acceptable for most credit card transactions, which is the combination of First Name, Last Name, Street Address, City, State, and Postal Code.
• It extracts customer information from the data structure, and then uses the key to query for the contact.
  • If a duplicate is found, it is reported.
  • If a duplicate is not found, it attempts to insert the contact into the contact table.

Transfer Cart Inbound Create Quote Process

The Transfer Cart Inbound Create Quote Process workflow process is shown in Figure 24.

Figure 24. Transfer Cart Inbound Create Quote Process

When this workflow is called, the following events happen:

• The unique identifier for the quote is the Destination Key. The Key is provided by the source system to reference objects on the external system. If this is the first request for a transfer of this cart, this value of the key should be empty. Then this workflow creates the cart and generate a new Key for the quote record.
• If this cart has been transferred before, then the key contains data, which is used to locate the existing cart on the destination system. The workflow updates this cart data.
• Finally, the Quote is attached to the correct contact and account Records (the customer data).

PRM ANI Inbound Addressing Change Process

The PRM ANI Inbound Addressing Change Process is shown in Figure 25.

Figure 25. PRM ANI Inbound Addressing Change Process

When this workflow is called, the following events happen:

• The first steps take the information about the system keys, internal and external, and uses it to judge whether we need to swap the Source Organization and Destination Channel Partner information in our message.
• If the key manipulation is handled elsewhere, the remaining steps are ignored.
• If the key manipulation is not handled elsewhere, the next steps swap the Source Organization and Destination Channel Partner data.
  • Since the fields (including the addresses) are the same, we simply alter the names of the components (Channel Partner Address becomes Organization Address, and so on. No data is actually moved.
  • The hierarchy component names are kept in process properties to allow for greater flexibility. If an integration component is renamed, a small change in the process properties is all that is needed.