Shopping Cart Transfer Workflows

The workflow processes described in this topic are associated with shopping cart transfers.

These processes 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, 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 workflows:

• "Transfer Cart Outbound Initial Workflow". This workflow manages the general process flow, from the selection of the destination organization to the acknowledgment processing.

• "Transfer Cart Outbound Request Process Workflow". This workflow 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 Workflow". This workflow gathers and sets data needed for the message header and creates the message header.

• "Transfer Cart Outbound Create and Append Process Workflow". This workflow is used in many places as a utility workflow that creates the child hierarchy and appends the child instance to the parent object.

• "Transfer Cart Outbound Receive Acknowledgment Process Workflow". This workflow handles 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 workflows:

• "Transfer Cart Inbound Receive Process Workflow". This workflow handles the initial processing of the data.

• "Transfer Cart Inbound Create Cart Process Workflow". This workflow 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 Process Workflow". This workflow inserts an account record if the data is present and viable. It returns an error if the data is not viable and skips the insert steps if the data is not present, assuming that the customer has only contact information and no account.

• "Transfer Cart Inbound Create Contact Process Workflow". This workflow creates the customer contact information if the data is present and viable. It returns an error if the data is not viable and assumes the contact is anonymous if the data is not present.

• "Transfer Cart Inbound Create Quote Process Workflow". This workflow creates the quote (persistent shopping cart) after checking the data for integrity.

• "PRM ANI Inbound Addressing Change Process Workflow". This workflow 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 stops and passes the error messages up to the calling process. The calling process then passes the error back to its calling process. When it reaches the top process, it returns an error saying that the transfer was unsuccessful.

Transfer Cart Outbound Initial Workflow

The Transfer Cart Outbound Initial workflow is shown in Figure 4-13.

Figure 4-13 Transfer Cart Outbound Initial Workflow

When this workflow is called, the following events happen:

• The first event checks for the availability of the items the customer wants to purchase.

• The next event finds the communication information associated with the partner and runs the Transfer Cart Outbound Request Process subprocess to create the shopping cart data structure.

• The next event checks to see if the brand owner is in debug mode (controlled by the Debug Flag in the Process Properties). If so, the brand owner needs 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 allows use of the Web Services instead. In this situation, 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 Workflow (either success or failure) as the final event in this workflow.

Transfer Cart Outbound Request Process Workflow

The Transfer Cart Outbound Request Process workflow is shown in Figure 4-14.

Figure 4-14 Transfer Cart Outbound Request Process Workflow

When this workflow is called, the following events happen:

• The first event creates the message header with information about the message itself including timestamps, and so on.

• The next event adds the shopping cart data (Quote, Quote Item, and so on) to the shopping cart data structure.

• The workflow then includes information about the source organization sending the data.

• Then, the workflow appends information about the destination partner to this message.

• Finally, the workflow adds the customer information, including account and customer data.

Transfer Cart Outbound Create Header Process Workflow

The Transfer Cart Outbound Create Header Process workflow is shown in Figure 4-15.

Figure 4-15 Transfer Cart Outbound Create Header Process Workflow

When this workflow is called, the following events happen:

• The early events gather and set data used in the message header as follows:

  • They set all of the key information first, including the internal key and key description. The external system uses this to reference a record in the Siebel database.

  • They also set the timestamps and status messages.

• The later events instantiate the header instance by creating an empty data structure based on the metadata provided by the integration object definition in Siebel Tools. They append all the data to the empty data structure.

Transfer Cart Outbound Create and Append Process Workflow

The Transfer Cart Outbound Create and Append Process workflow is shown in Figure 4-16.

Figure 4-16 Transfer Cart Outbound Create and Append Process Workflow

When this workflow is called, the following events happen in this order:

• The workflow 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.

• The workflow appends the child instance to the parent object (usually this is the shopping cart object). If a flag is set, it can create an empty parent and append this child to it.

Transfer Cart Outbound Receive Acknowledgment Process Workflow

The Transfer Cart Outbound Receive Acknowledgment Process workflow is shown in Figure 4-17.

Figure 4-17 Transfer Cart Outbound Receive Acknowledgement Process Workflow

When this workflow is called, the following events happen in this order:

• The workflow gets the status of the message that has been received and looks for the partner it was received from.

• The workflow looks for an existing Keymap record that indicates whether to update it or create a new record. The Keymap data includes a record of the transferred information, including the time of the last transfer and the key used to reference the shopping cart's counterpart in the external system.

• If there is no error, the workflow 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, the workflow presents the customer with an option view that allows him or her to decide whether to choose another partner or cancel the transaction.

Transfer Cart Inbound Receive Process Workflow

The Transfer Cart Inbound Receive Process workflow is shown in Figure 4-18.

Figure 4-18 Transfer Cart Inbound Receive Process Workflow

When this workflow is called, the following events happen in this order:

• The workflow makes sure that the sender is someone that is authorized to send requests.

• The workflow checks that the external system's key is present, and that the brand owner is the intended recipient.

• The workflow gets the key description and runs the Transfer Cart Inbound Create Cart Process.

• If an error is generated, the workflow reports it to the calling system and finishes the process. No Keymap record is created because the quote might not have been created.

• If no error is generated (OK status), the workflow does the following:

  • 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 to the caller.

Transfer Cart Inbound Create Cart Process Workflow

The Transfer Cart Inbound Create Cart Process workflow is shown in Figure 4-19.

Figure 4-19 Transfer Cart Inbound Create Cart Process Workflow

When this workflow is called, it performs the following events in this order:

• Checks for the quote

• Inserts the customer account information

• Inserts the customer contact information

• Inserts the quote information and links it to the customer information

PRM ANI Inbound Create Account Process Workflow

The PRM ANI Inbound Create Account Process workflow is shown in Figure 4-20.

Figure 4-20 PRM ANI Inbound Create Account Process Workflow

When this workflow is called, it performs the following events in this order:

• Checks to see if the Account Name and D-U-N-S number are viable

• Looks in the Siebel database for an account with the same D-U-N-S number. This number is the Siebel method of uniquely identifying an account or partner.

  • If the account is found, reports the record's ID

  • If the account is not found, creates a new account

Transfer Cart Inbound Create Contact Process Workflow

The Transfer Cart Inbound Create Contact Process workflow is shown in Figure 4-21.

Figure 4-21 Transfer Cart Inbound Create Contact Process workflow

When this workflow is called, it performs the following events in this order:

• 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

• 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

• 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 Workflow

The Transfer Cart Inbound Create Quote Process workflow is shown in Figure 4-22.

Figure 4-22 Transfer Cart Inbound Create Quote Process Workflow

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, the value of the key is empty. Then, the workflow creates the cart and generates a new key for the Quote record.

• If this cart has been transferred before, then the key contains data that 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 Workflow

The PRM ANI Inbound Addressing Change Process workflow is shown in Figure 4-23.

Figure 4-23 PRM ANI Inbound Addressing Change Process Workflow

When this workflow is called, the following events happen:

• The first events take the information about the system keys, internal and external, and use it to judge whether to swap the source organization and destination channel partner information in the message.

• If the key manipulation is handled elsewhere, the remaining steps are ignored.

• If the key manipulation is not handled elsewhere, the next events swap the source organization and destination channel partner data as follows:

  • Because the fields (including the addresses) are the same, the names of the components are altered. For example, Channel Partner Address becomes Organization Address. 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.