Architecture: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 2: | Line 2: | ||
# '''Process Apps'''</br>A Process Application is the container for a solution, much like a project. First you will create the Process Application within the Process Center Console and you give it both name and a unique tag, or an acronym, that is no more than seven characters in length. Once created, a Process Application can have additional artifacts added to it using the BPM Process Designer (PD) tooling. Both the Process Application and its artifacts are stored in a repository managed by the Process Center. </br>Process Applications can be created via the Process Center console, either via its web interface or from within BPM PD. The button to create a new Process Application is on the main Process Apps page. When a new Process Application is created, a dialog opens asking for a name and acronym for the new application. </br>A "state" of the Process Application can be captured in a "snapshot" anytime. In creating a snapshot, all artifacts and their respective content are captured at that moment. Modifications done to the Process Application after the snapshot are not represented in previous snapshots. More snapshots can be created anytime. </br>Process Applications generally house one or more Business Process Definitions. These Business Process Definitions are models of processes that at some future date will become executable. In this book, I make use of the terminologies BPDs and BPMN processes interchangeably since they mean the same thing. | # '''Process Apps'''</br>A Process Application is the container for a solution, much like a project. First you will create the Process Application within the Process Center Console and you give it both name and a unique tag, or an acronym, that is no more than seven characters in length. Once created, a Process Application can have additional artifacts added to it using the BPM Process Designer (PD) tooling. Both the Process Application and its artifacts are stored in a repository managed by the Process Center. </br>Process Applications can be created via the Process Center console, either via its web interface or from within BPM PD. The button to create a new Process Application is on the main Process Apps page. When a new Process Application is created, a dialog opens asking for a name and acronym for the new application. </br>A "state" of the Process Application can be captured in a "snapshot" anytime. In creating a snapshot, all artifacts and their respective content are captured at that moment. Modifications done to the Process Application after the snapshot are not represented in previous snapshots. More snapshots can be created anytime. </br>Process Applications generally house one or more Business Process Definitions. These Business Process Definitions are models of processes that at some future date will become executable. In this book, I make use of the terminologies BPDs and BPMN processes interchangeably since they mean the same thing. | ||
# '''Toolkits''' </br> A Toolkit can be considered as a container for artifacts used in solutions, much like a Process Application. However, unlike a Process Application, a Toolkit itself does not result in a deployable application. Rather, the contents of the Toolkit may be "included" or "used" by one or more Process Applications. </br> Whenever Process Center is installed and configured, an IBM-supplied Toolkit called "System Data" gets automatically imported into the repository. See System Data Toolkit for more details. </br> This toolkit is marked as read-only and it is implicitly dependent on all other Process Applications and Toolkits. The System Data Toolkit contains core definitions for data structures and other items common across all Process Applications. </br> The toolkits have their own tabs in the Process Center console. There, creation, exportation, management of new toolkits can be done similarly to process applications.</br> Similarly, as in Process Application, one can take snapshots of Toolkits. By doing this, all artifacts inside a toolkit are considered a particular version. In order to add a toolkit as a dependency of a Process Application, the toolkit itself must first have at least one snapshot associated with it. This is because the dependency added to the Process Application is not just the name of the Toolkit, but a snapshot of that Toolkit. Once a snapshot of the Toolkit has been taken, in the Designer view of PD a dependency can be added by clicking the + icon next to the Toolkits entry. A list of potential Toolkits and their associated snapshots will be shown for selection.<br> | # '''Toolkits''' </br> A Toolkit can be considered as a container for artifacts used in solutions, much like a Process Application. However, unlike a Process Application, a Toolkit itself does not result in a deployable application. Rather, the contents of the Toolkit may be "included" or "used" by one or more Process Applications. </br> Whenever Process Center is installed and configured, an IBM-supplied Toolkit called "System Data" gets automatically imported into the repository. See System Data Toolkit for more details. </br> This toolkit is marked as read-only and it is implicitly dependent on all other Process Applications and Toolkits. The System Data Toolkit contains core definitions for data structures and other items common across all Process Applications. </br> The toolkits have their own tabs in the Process Center console. There, creation, exportation, management of new toolkits can be done similarly to process applications.</br> Similarly, as in Process Application, one can take snapshots of Toolkits. By doing this, all artifacts inside a toolkit are considered a particular version. In order to add a toolkit as a dependency of a Process Application, the toolkit itself must first have at least one snapshot associated with it. This is because the dependency added to the Process Application is not just the name of the Toolkit, but a snapshot of that Toolkit. Once a snapshot of the Toolkit has been taken, in the Designer view of PD a dependency can be added by clicking the + icon next to the Toolkits entry. A list of potential Toolkits and their associated snapshots will be shown for selection. Every solution developed using IBM BPM is encapsulated in its own Process Application (Process App). The Process App is the deployable unit to a Process Server for execution. This is all very well when developing just one solution, but when a second solution is developed, it soon becomes apparent that many of the first solution's artifacts can be used by the second. While it is certainly possible to copy these artifacts from one solution into another, this results in duplication. Any changes to one of the copies would either have to be repeated in the other or risk the copies getting out of sync. A better option is to be able to have a single definition of an artifact that can be used by both solutions. This produces a set of common artifacts used by applications. This concept is supported by IBM BPM through the use of "toolkits." A toolkit is a named collection of artifacts that differ from a process application in one critical way: it doesn't deploy. Artifacts contained in a created toolkit can then be used in other process apps, and even in other toolkits, by declaring dependencies. The dependency is declared; the artifacts inside that toolkit are then wholly available to the solution—as if they were copied in—without the actual duplication. As with any human endeavor, there is a right and wrong way to go about organizing artifacts in a toolkit. We will now consider some suggestions on what tends to work well and what doesn't.<br> | ||
# '''IBM BPM Components''' | # '''IBM BPM Components''' | ||
#* Process Server | #* Process Server | ||
Revision as of 23:40, 5 August 2024
Below are the components in IBM BPM architecture:
- Process Apps
A Process Application is the container for a solution, much like a project. First you will create the Process Application within the Process Center Console and you give it both name and a unique tag, or an acronym, that is no more than seven characters in length. Once created, a Process Application can have additional artifacts added to it using the BPM Process Designer (PD) tooling. Both the Process Application and its artifacts are stored in a repository managed by the Process Center.
Process Applications can be created via the Process Center console, either via its web interface or from within BPM PD. The button to create a new Process Application is on the main Process Apps page. When a new Process Application is created, a dialog opens asking for a name and acronym for the new application.
A "state" of the Process Application can be captured in a "snapshot" anytime. In creating a snapshot, all artifacts and their respective content are captured at that moment. Modifications done to the Process Application after the snapshot are not represented in previous snapshots. More snapshots can be created anytime.
Process Applications generally house one or more Business Process Definitions. These Business Process Definitions are models of processes that at some future date will become executable. In this book, I make use of the terminologies BPDs and BPMN processes interchangeably since they mean the same thing. - Toolkits
A Toolkit can be considered as a container for artifacts used in solutions, much like a Process Application. However, unlike a Process Application, a Toolkit itself does not result in a deployable application. Rather, the contents of the Toolkit may be "included" or "used" by one or more Process Applications.
Whenever Process Center is installed and configured, an IBM-supplied Toolkit called "System Data" gets automatically imported into the repository. See System Data Toolkit for more details.
This toolkit is marked as read-only and it is implicitly dependent on all other Process Applications and Toolkits. The System Data Toolkit contains core definitions for data structures and other items common across all Process Applications.
The toolkits have their own tabs in the Process Center console. There, creation, exportation, management of new toolkits can be done similarly to process applications.
Similarly, as in Process Application, one can take snapshots of Toolkits. By doing this, all artifacts inside a toolkit are considered a particular version. In order to add a toolkit as a dependency of a Process Application, the toolkit itself must first have at least one snapshot associated with it. This is because the dependency added to the Process Application is not just the name of the Toolkit, but a snapshot of that Toolkit. Once a snapshot of the Toolkit has been taken, in the Designer view of PD a dependency can be added by clicking the + icon next to the Toolkits entry. A list of potential Toolkits and their associated snapshots will be shown for selection. Every solution developed using IBM BPM is encapsulated in its own Process Application (Process App). The Process App is the deployable unit to a Process Server for execution. This is all very well when developing just one solution, but when a second solution is developed, it soon becomes apparent that many of the first solution's artifacts can be used by the second. While it is certainly possible to copy these artifacts from one solution into another, this results in duplication. Any changes to one of the copies would either have to be repeated in the other or risk the copies getting out of sync. A better option is to be able to have a single definition of an artifact that can be used by both solutions. This produces a set of common artifacts used by applications. This concept is supported by IBM BPM through the use of "toolkits." A toolkit is a named collection of artifacts that differ from a process application in one critical way: it doesn't deploy. Artifacts contained in a created toolkit can then be used in other process apps, and even in other toolkits, by declaring dependencies. The dependency is declared; the artifacts inside that toolkit are then wholly available to the solution—as if they were copied in—without the actual duplication. As with any human endeavor, there is a right and wrong way to go about organizing artifacts in a toolkit. We will now consider some suggestions on what tends to work well and what doesn't. - IBM BPM Components
- Process Server
- Process Center
- Process Designer
- Performance Datawarehouse
- Process Center Console
- Process Portal
- Process Admin Console