Understanding > WebSphere Commerce and service-oriented architecture (SOA) > WebSphere Commerce Web services > WebSphere Commerce BOD command framework > Business logic layer design patterns

Commerce Feature Pack

Business Object Document Change processing pattern

The Business Object Document Change processing pattern adds, changes, or deletes a business object. This processing pattern is similar to the SOI Change pattern. In the SOI Change pattern implementation, Change requests map to existing WebSphere Commerce controller commands. The request Business Object Document is converted into the name-value pair parameters that are passed to the controller command. This enables reuse of existing business logic as a service. One limitation of this implementation is that the SOI Change request can only have one action. Because this design pattern uses BOD processing commands, the limitation of one action in the Change request is lifted. The other major difference is that the BOD Change pattern uses service data objects (SDO) to pass data, instead of name-value pairs.

For the Change request processing pattern, the logic is divided into three command types:

Change controller command

Helps to break the request into smaller tasks and execute these tasks. These smaller task commands will act upon parts of the noun (also known as noun parts) instead of the entire noun. The controller also attempts to fetch the required data for the request up-front and pass this data to the other task commands, so that the command will use and update common data elements. This is to avoid data collision between task commands where they may act upon the same data, avoiding the performance overhead of each task committing changes independently. Once all the tasks are executed, the data read up-front is persisted so the changes are committed in the database.

Business logic Create, Update and Delete task commands

These commands perform the appropriate action on the noun. These tasks only deal with a specific part of the noun and is passed the action to perform, the part of the noun that has changed and the original request noun along with the data that was retrieved by the controller. The controller can have many instances of these task commands to act upon the many noun parts that are being changed as part of the message. The controller is responsible for executing the different task commands to perform the entire change operation. The business logic tasks only need to understand how to deal with a particular noun part being modified.

PostChangeNounPart command

This command contains any post-requisite business logic that may result because of a change of that part of the noun. These business logic tasks may not be necessary but there are cases where business logic is needed as a result of changing specific parts of a business object. For example, a special command may be called to evaluate inventory position, when significant inventory changes have been made. The change controller will create instances of these business tasks and execute them after performing the change actions. These tasks is given the actions performed on the part, the original request noun, and the data retrieved by the controller (which has not yet been persisted). These business logic tasks are optional, so if no implementation is found then the change controller will assume no additional business logic is required.

The following steps describe the detailed flow of the Change processing pattern:

  1. The Change noun controller command divides the BOD and calls read() to resolve the root objects of the nouns to change. The root object is the primary record of the business object.

  2. The validate() method is called to perform any common validation that is required.

  3. An access control check is performed to ensure the current user has permission to change the specified noun.

  4. The Change noun part task commands are instantiated and for each command, the validate() method is executed to report potential errors that can occur during processing.

    1. The Change noun part command will read any information required and validate the input.

  5. The Change noun part task command is executed to perform the change.

    1. The Change noun part applies the changes.

    2. The Change noun part saves any changes made to data objects retrieved in the current instance of the command.

  6. The post change noun part command is instantiated and executed.

    1. More data is read in the findObjects() method.

    2. Other data may be changed in the applyChanges() method.

    3. Any changes are saved in the saveObject() method.

  7. The save is called on the object retrieved in step 1.

  8. The response is created and returned.

Related concepts

Business Object Document Process processing pattern

Business Object Document Sync processing pattern

Related tasks

Developing BOD Process, Change, and Sync services

Add a new action to a BOD Process service

Extending a Process action

Exchanging data with an external system before performing a Process, Change, or Sync service

Add post-processing business logic for Change and Sync services

Use the ChangeNounPart pattern to validate a noun part

Last updated: 25 November 2009