Customer pipelines
CreateUser pipeline
Depending on the actual integration with ECS and the solution then the user can be disabled by default and will be activated when ActivateUserAccount
is called.
Name: |
CreateUser |
Description: |
This pipeline is responsible for creating a user account. |
Usage: |
Called from Sitecore. |
Args: | |
Request - Contains the user entity and a password. Is set prior to calling the pipeline. | |
Response - Contains the user object. Is read after the pipeline is called. | |
Processors: | |
CreateUserInECS – Optional Creates a user in the external commerce system and updates the ExternalID field on the user entity. Note If External ID is parsed in and the user already exists, nothing should happen. This processor is optional but recommended if CommerceUsers are supported in the ECS. | |
CreateUserInCMS – (Mandatory) Creates the user but more importantly stores the relation to If the user already exists, then the pipeline should be aborted to avoid triggering the goal. Note This processor is mandatory to store the one-to-many relationship between the | |
TriggerDMSGoal – The User Account Created goal is triggered with the following values: User name and ShopName. |
UpdateUser pipeline
Name: |
UpdateUser |
Description: |
This pipeline is responsible for updating an existing user account. |
Usage: |
Called from Sitecore. |
Args: | |
Request - Contains the user entity. Is set prior to calling the pipeline. | |
Response - Contains the user entity. Is read after the pipeline is called. | |
Processors: | |
UpdateUserInECS – Optional . Updates an existing user account in the external commerce system. Note This processor is optional but recommended if | |
UpdateUserInCMS – Mandatory Updates the user account in the Sitecore. Since the user is updated externally first, then the user data can be changed there and the final version is stored in CMS. Note This processor is mandatory to store the one-to-many relationship between the | |
TriggerDMSEvent – The page User Account Updated event is triggered with the following values: User name and ShopName. |
DeleteUser pipeline
Name: |
DeleteUser |
Description: |
This pipeline is responsible for deleting an existing user account. |
Usage: |
Called from Sitecore. |
Args: | |
Request - Contains the user entity. Is set prior to calling the pipeline. | |
Response - | |
Processors: | |
DeleteUserInECS – Optional . Deletes an existing user in the external commerce system. Note If the user account does not exist, it can be noted in the returned collection of the External System Messages, but the pipeline must continue. This processor is optional but recommended if | |
DeleteUserInCMS – Mandatory . Deletes the user in the Sitecore. Note If the user account does not exist, the pipeline is aborted. This processor is mandatory to store the one-to-many relationship between the | |
TriggerDMSEvent – The User Account Deleted page event is triggered with the following values: User name and ShopName. |
DisableUser pipeline
Name: |
DisableUser |
Description: |
This pipeline is responsible for disabling an existing user account. |
Usage: |
Called from Sitecore. |
Args: | |
Request - Contains the user entity and a comment. Is set prior to calling the pipeline. | |
Response - Is read after the pipeline is called. | |
Processors: | |
DisableUserInECS – Optional . Disables an existing user in the external commerce system. | |
DisableUserInCMS – Mandatory . Disables the user in Sitecore. Note Since the user is attempted to be disabled externally first, then it is possible that the pipeline is aborted due to business rules and the users are still synchronized. This processor is mandatory to store the one-to-many relationship between the | |
TriggerDMSEvent – The User Account Disabled page event is triggered with the following values: User name, ShopName, and the provided comment. |
EnableUser pipeline
Name: |
EnableUser |
Description: |
This pipeline is responsible for enabling an existing user account. |
Usage: |
Called from Sitecore. |
Args: | |
Request - Contains the user entity and a comment. Is set prior to calling the pipeline. | |
Response - Is read after the pipeline is called. | |
Processors: | |
EnableUserInECS – Optional . Enables an existing user in the external commerce system. Note Either this processor or the next should be in the pipeline, normally not both. | |
EnableUserInCMS – Mandatory . Enables the user in Sitecore. Note Since the user is attempted to be enabled externally first, then it is possible that the pipeline is aborted due to business rules and the users are still synchronized. This processor is mandatory to store the one-to-many relationship between the | |
TriggerDMSEvent – The User Account Enabled goal is triggered with the following values: User name, ShopName and the provided comment. |
GetUser pipeline
Name: |
GetUser |
Description: |
Returns a single user account. |
Usage: |
Called from Sitecore when a visitor a specific user account is needed |
Args: | |
Request - Contains ShopName and User ID. Is set prior to calling the pipeline. | |
Response – Returns a single user entity.Is read after the pipeline is called. | |
Processors: | |
GetUserFromECS – Optional Gets the specified user from the external commerce system. Note Either this processor or the next should be in the pipeline, normally not both. This processor is optional but recommended if | |
GetUserFromCMS – Mandatory . Gets the specified user from the CMS. Note Either this processor or the previous one should be in the pipeline, normally not both. |
GetUsers pipeline
Name: |
GetUsers |
Description: |
Queries and returns user accounts. Different input parameters can be provided and they will be combined using logical and. |
Usage: |
Called from Sitecore when a visitor is registering for an account. It could be during the checkout process or through plain signup. |
Args: | |
Request - Contains search parameters. Is set prior to calling the pipeline. | |
Response – Returns a list of user entities.Is read after the pipeline is called. | |
Processors: | |
GetUsersFromECS – Optional Queries against users in the external commerce system. Note Either this processor or the next should be in the pipeline, normally not both. This processor is optional but recommended if | |
GetUsersFromCMS – Mandatory . Queries against users in CMS. Note Either this processor or the previous one should be in the pipeline, normally not both. |
CreateCustomer pipeline
Name: |
CreateCustomer |
Description: |
This pipeline is responsible for creating a customer account. The customers are managed by the commerce system. |
Usage: |
Called from Sitecore |
Args: | |
Request - Contains the customer entity. Is set prior to calling the pipeline. | |
Response - Contains the customer entity after the pipeline is called. | |
Processors: | |
CreateCustomerInECS – Optional Depends on whether Customers are supported in the ECS Creates the customer in the external commerce system. It involves:
Note If External ID is parsed in and the customer already exists, nothing should happen. | |
CreateCustomerInSitecore – (Mandatory) Creates the customer in Sitecore. Note This processor is mandatory to store the one-to-many relationship between the CommerceUser and CommerceCustomers. If that is handled in the ECS, the processor is not mandatory. | |
TriggerDMSGoal – The Customer Account Created goalis triggered with the following values: customer name and ShopName |
UpdateCustomer pipeline
Name: |
UpdateCustomer |
Description: |
This pipeline is responsible for updating an existing customer account. The customers are managed by the commerce system. |
Usage: |
Called from Sitecore. |
Args: | |
Request - Contains the customer entity. Is set prior to calling the pipeline. | |
Response - Contains the customer object. Is read after the pipeline is called. | |
Processors: | |
UpdateCustomerInECS – Mandatory . Updates the customer in the external commerce system. | |
SaveCustomertoEAState – Mandatory . Updates the customer stored in the EA state based on the updated CommerceCustomer returned from the previous processor. | |
TriggerDMSEvent – The Customer Account Updated goal is triggered with the following values: customer name and ShopName. |
DeleteCustomer pipeline
Name: |
DeleteCustomer |
Description: |
This pipeline is responsible for deleting an existing customer account. The customers are managed by the commerce system. |
Usage: |
Called from Sitecore. |
Args: | |
Request - Contains the customer entity. Is set prior to calling the pipeline. | |
Response - | |
Processors: | |
DeleteCustomerInECS – Mandatory . Deletes the customer in the external system. Note If the customer account does not exist, it can be noted in the returned collection of the External System Messages, but the pipeline must continue. | |
RemoveCustomerFromEAState – Mandatory . Removes the customer stored in the EA state. | |
TriggerDMSEvent – The Customer Account Deleted goal is triggered with the following values: customer name and ShopName. |
DisableCustomer pipeline
Name: |
DisableCustomer |
Description: |
This pipeline is responsible for disabling an existing customer account. |
Usage: |
Called from Sitecore. |
Args: | |
Request - Contains the customer entity and a comment. Is set prior to calling the pipeline. | |
Response – The disabled customer entity. Is read after the pipeline is called. | |
Processors: | |
DisableCustomerInECS – Disables an existing customer in the external commerce system. | |
SaveCustomertoEAState – Mandatory. Updates the customer stored in the EA state based on the updated CommerceCustomer returned from the previous processor. | |
TriggerDMSEvent – The Customer Account Disabled page event is triggered with the following values: Name, ShopName, and the provided comment. |
EnableCustomer pipeline
Name: |
EnableCustomer |
Description: |
This pipeline is responsible for enabling an existing customer account. |
Usage: |
Called from Sitecore. |
Args: | |
Request - Contains the customer entity and a comment. Is set prior to calling the pipeline. | |
Response – The enabled customer entity. Is read after the pipeline is called. | |
Processors: | |
EnableCustomerInECS – Enables an existing customer in the external commerce system. | |
SaveCustomertoEAState – Mandatory. Updates the customer stored in the EA state based on the updated CommerceCustomer returned from the previous processor. | |
TriggerDMSEvent – The Customer Account Enabled page event is triggered with the following values: Name, ShopName, and the provided comment. |
GetCustomer pipeline
Name: |
GetCustomer |
Description: |
Returns the single customer entity with the specified ID. Whether the customer is retrieved from the ECS or the CMS depends on the support of customers in the ECS. |
Usage: |
Called from Sitecore. |
Args: | |
Request - Contains shop name and Customer ID. Is set prior to calling the pipeline. | |
Response - Returns a single customer entity after the pipeline is called. | |
Processors: | |
GetCustomerFromECS – Optional. Gets the specified customer from the external commerce system. Note Either this processor or the next should be in the pipeline, normally not both. | |
GetCustomersFromCMS – Mandatory. Gets the specified customer from the CMS. Note Either this processor or the previous one should be in the pipeline, normally not both. |
GetCustomers pipeline
Name: |
GetCustomers |
Description: |
Queries and returns customer accounts. Different input parameters can be provided and they will be combined using logical and. Whether the customers are retrieved from the ECS or CMS depends on the support of customers in the ECS. |
Usage: |
Called from Sitecore. |
Args: | |
Request - Contains search parameters. Is set prior to calling the pipeline. | |
Response - Returns a list of customer entities after the pipeline is called. | |
Processors: | |
GetCustomersFromECS – Optional. Queries against customers in the external commerce system. If the required search functionality is not supported in the ECS, then it can potentially be handled by searching for customers in the CMS. Note: Either this processor or the next should be in the pipeline, normally not both. | |
GetCustomersFromCMS – Optional. Queries against Customers in the CMS. If the required search functionality is not supported in the CMS, then it can potentially be handled by searching for users in the ECS. Note: Either this processor or the previous one should be in the pipeline, normally not both. |
AddCustomerParties pipeline
Name: |
AddCustomerParties |
Description: |
This pipeline is responsible for adding customer parties to the specified customer |
Usage: |
Called from Sitecore. |
Args: | |
Request - Contains a customer and a list of CustomerParty instances. Is set prior to calling the pipeline. | |
Response – A new instance of the customer.Is read after the pipeline is called. | |
Processors: | |
AddCustomerParties – Responsibility: Adds the provided parties to the customer account and persists them. Usage: Mandatory. Ownership: The processor is provided with Connect and stores the parties with the customer account using the Sitecore membership provider. Customization: No immediate need to customize. There should be a separate processor for storing the parties in the ECS. The processor should either replace this processor or be added in addition to this processor. |
RemoveCustomerParties pipeline
Name: |
RemoveCustomerParties |
Description: |
This pipeline is responsible for removing customer parties from the specified customer. |
Usage: |
Called from Sitecore. |
Args: | |
Request - Contains a customer and a list of CustomerParty instances. Is set prior to calling the pipeline. | |
Response – A new instance of the customer.Is read after the pipeline is called. | |
Processors: | |
RemoveCustomerParties – Responsibility: Is to remove the provided parties from the customer account. Usage: Mandatory. Ownership: The processor is provided with Connect and removes the parties that will no longer be persisted anywhere in Sitecore. Customization: No immediate need to customize. There should be a separate processor for storing the parties in the ECS. The processor should either replace this processor or be added in addition to this processor. |
UpdateCustomerParties pipeline
Name: |
UpdateCustomerParties |
Description: |
This pipeline is responsible for updating customer parties on the specified customer. |
Usage: |
Called from Sitecore. |
Args: | |
Request - Contains a customer and a list of CustomerParty instances. Is set prior to calling the pipeline. | |
Response – A new instance of the customer.Is read after the pipeline is called. | |
Processors: | |
UpdateCustomerParties – Responsibility: Updates the provided parties on the customer account and persists them. Usage: Mandatory. Ownership: The processor is provided with Connect and stores the updated parties with the customer account using the Sitecore membership provider. Customization: No immediate need to customize. There should be a separate processor for storing the parties in the ECS. The processor should either replace this processor or be added in addition to this processor. |
AddParties pipeline
Name: |
AddParties |
Description: |
This pipeline is responsible for adding parties to the specified customer. |
Usage: |
Called from Sitecore. |
Args: | |
Request - Contains a customer and a list of CustomerParty instances. Is set prior to calling the pipeline. | |
Response – A new instance of the customer.Is read after the pipeline is called. | |
Processors: | |
AddParties – Responsibility: Adds the provided parties to the customer account and persists them. Usage: Mandatory. Ownership: The processor is provided with Connect and stores the parties with the customer account using the Sitecore membership provider. Customization: No immediate need to customize. There should be a separate processor for storing the parties in the ECS. The processor should either replace this processor or be added in addition to this processor. |
RemoveParties pipeline
Name: |
RemoveParties |
Description: |
This pipeline is responsible for removing parties stored with the specified customer. |
Usage: |
Called from Sitecore. |
Args: | |
Request - Contains a customer and a list of party instances. Is set prior to calling the pipeline. | |
Response – A new instance of the customer.Is read after the pipeline is called. | |
Processors: | |
RemoveParties – Responsibility: Removes the provided parties from the customer account. Usage: Mandatory. Ownership: The processor is provided with Connect and removes the parties that will no longer be persisted anywhere in Sitecore. Customization: No immediate need to customize. There should be a separate processor for storing the parties in the ECS. The processor should either replace this processor or be added in addition to this processor. |
UpdateParties pipeline
Name: |
UpdateParties |
Description: |
This pipeline is responsible for updating customer parties on the specified customer. |
Usage: |
Called from Sitecore. |
Args: | |
Request - Contains a customer and a list of CustomerParty instances. Is set prior to calling the pipeline. | |
Response – A new instance of the customer.Is read after the pipeline is called. | |
Processors: | |
UpdateParties – Responsibility: Updates the provided parties on the customer account and persists them. Usage: Mandatory. Ownership: The processor is provided with Connect and stores the updated parties with the customer account using the Sitecore membership provider. Customization: No immediate need to customize. There should be a separate processor for storing the parties in the ECS. The processor should either replace this processor or be added in addition to this processor. |
GetParties pipeline
Name: |
GetParties |
Description: |
This pipeline is responsible for getting the parties. |
Usage: |
Called from Sitecore. |
Args: | |
Request - Contains a customer. Is set prior to calling the pipeline. | |
Response – A list of parties. Is read after the pipeline is called. | |
Processors: | |
GetParties – Responsibility: Is to return the complete list of parties stored with the customer. Usage: Mandatory. Ownership: The processor is provided with Connect and stores the parties with the customer account using the Sitecore membership provider. Customization: No immediate need to customize. There should be a separate processor for storing the parties in the ECS. The processor should either replace this processor or be added in addition to this processor. |