Solution Patterns help to unlock the business requirements for case-based solutions. They articulate what we want the solution to do. Next we turn to the question of how. Design Patterns describe how the technology – xCP – can be brought to bear on the solution implementation.
A Design Pattern
To be concrete let’s consider a specific example of a Design Pattern: Initiate Process by SQL Query. Case-based solutions are constructed from networks of processes and these processes need to be initiated in some way. One way is to initiate a process manually, for example by a user pressing a button. Other processes are initiated automatically, especially utility processes. A process can be initiated by a database event. For example, when a certain data field changes from 0 to 1, this means that new data is available for my case. A listener notices that the value has changed from 0 to 1 and initiates the process, which queries the database for the new information and then uses this information in the new process. The Design Pattern for this example is documented in the EDN – https://community.emc.com/docs/DOC-11210 . It describes how to set up the listener, using a DB Inbound Initiate Activity Template and how to configure the database query to run. Once you see the pattern, you can use this approach in many different case-based solutions.
Categories of Design Patterns
If you are a developer, then you will probably be interested in solving some specific problem or class of problems. You want to find the design pattern to solve your problem. To facilitate your search, the Design Patterns are organized by type. In the EDN you will find the following categories:
- Activity Pattern
- Data Structures
- Look and Feel
- Process Pattern
- User Interaction
So, if you wanted to know how to change the appearance of your forms, you would go to the “Look and Feel” category. There you might decide to use the Rounded Corner Style with Border Design Pattern. If you wanted to use Adobe PDF forms as a way of inputting data to xCP, you would look at the Integration category. There you would find just the right design pattern: PDF Forms with xCP. Or suppose that you wanted to trigger a process from a BAM alert. You would find that Design Pattern in the Reporting category.
Design Patterns have real and important benefits. Here are three of them:
1. Faster development. Clearly if you have a design pattern for your implementation problem, you are in a better position than if you had only a blank sheet of paper. You can always make variations on the pattern but having a clear design to start with will save time.
2. Consistency. Design patterns facilitate consistency of implementation. When you initiate a process, you will always do it in a consistent way. When you design a user interface, it will have a uniform look and feel. There is greater predictability in the solutions you create. Users know what to expect from their solution in appearance and behavior.
3. Reuse. Once you have implemented a design pattern, that design can be reused across different solutions. It is easy for other developers who share the language of Design Patterns to understand what you are doing. In general, Design Patterns foster transparency at the architectural level.
In our next post, we will tie the Design Patterns with the Solution Patterns.