With IBM BPM 8.5.5, the features needed to express both BPM solutions and case management oriented solutions comes together in one offering.

Transcription

1 Case Management With the release of IBM BPM 8.5.5, case management capabilities were added to the product. It must be noted that these functions are only available with IBM BPM Advanced and the Basic Case Management feature installed and licensed. The notion up till now is that processes can be articulated as a flow of activities. These are termed "routine work-flow" in that they can be repeatedly followed without too much in the way of deviation from expectations. However, not all processes can be modeled in such a fashion or, if they can be modeled, the effort of creating and maintaining them would far greater than any benefit that might be accrued from such an activity. When we model processes using BPM, we are primarily thinking in terms of how we achieve a result or goal or outcome. We are thinking about the steps involved from getting from the start to the end. With case management, we concern ourselves less with how we achieve a result/goal/outcome but instead think of merely achieving the result/goal/outcome (I'll stop saying all these now and just use "outcome"). The way the outcome is achieved is not necessarily described as a predefined sequence but is instead left to the skills of the knowledge worker to achieve. This may sound like a weaker story than BPM modeling but there are desired outcomes that would be difficult or impossible to model as a flowing processes. The way that the outcome is reached can simply not be prescribed by following a flowchart. For these types, should we just give up and not try and provide IT support for the knowledge worker? Obviously the answer is no and the techniques and capabilities provides by a Case Management System need to differ from those provided by just a Business Process Management System. With IBM BPM 8.5.5, the features needed to express both BPM solutions and case management oriented solutions comes together in one offering. When starting to work with case capabilities, we need to first define some terms that will be used. IBM advertises the Case Type as the way in which Case Management solutions should be built and, indeed, the majority of case oriented solutions can be constructed this way. In fact, for someone who is business oriented with low technology skills, this may be the only achievable way. However, with this said, if one looks slightly behind the curtain of how the IBM BPM product implements the case constructs, we will quickly find that the reality is that the "fancy web

2 tooling" is actually a facade upon BPDs that we already know and love. To make case management possible, the BPD technology (from onwards) added the notion of "Activity Behaviors". That phrase by itself tells us little but if one reads the corresponding documentation under that banner, one will immediately see its relationship to the notion of Case Management. To create a new case type, we can select the new Case Type button from the library area inside Process Designer: We are then prompted to provide a name for our new case type:

3 Once performed, we are brought up into our Case Type editor within the Web Process Designer. This has a number of tabs within it which allow us to configured the Case Type settings.

4 When we model a BPM process, the diagram of the process itself can act as a great source of documentation of the intent of the process. By reading through the steps and paths, we can relatively quickly appreciate its purpose. This is not true with Case Management solutions. There is no similar diagram against which we can quickly refer to understand the nature of the story. As such, it is essential that the Case Type contain a well written description of the goal of the case. A future reader should be able to read the description and come away with a comprehension for what its conclusion should achieve. This is not the same as describing how such an outcome is reached, that is the nature of the activities performed as part of the case, rather the description should capture the intent. Instead of opening Process Designer merely to open the Case editors within the Web Process Designer, we can configure a process app to allow us to launch the Web Process Designer directly. When a new Process App is first created, we can flag that it can be opened in the Web Process Designer:

5 Alternatively, if the Process App was created without providing this permission the authority can be added later. Within the Manage tab of a Process App in Process Center, a suitably authorized user can check the box titled " Allow users to open the process application in the web-base Case Designer ":

6 Once done, from within the Web based Process Center, we can now open the Case for development directly from the web page: Starting a new Case instance Case instances can be started (primarily) by two distinct techniques. The first is simply exposing the case to be started from within Process Portal. This is flagged in the Overview tab of the case model under the Exposing section:

7 A BPM team can be supplied here and user's who are members of that team will see an entry to start a new instance. By default, there is no associated team and hence a case instance may not be started in that fashion. The second mechanism for starting an instance of a case is by supplying a starting document type. This again can be supplied in the Overview tab of the case model under the Starting Document section:

8 Again, by default, no value is supplied here. To understand this option further, think of the BPM runtime asking the ECM environment that it should be told whenever a document of the named type is created. When ECM tells BPM that such an event has happened, that causes an instance of the case to be created and associated with the document. A final way that a Case instance can be started is through the use of the JavaScript API called tw.system.startprocessbyname(). Providing this call with the name of the Case Type will cause an instance of it to be started. Case Activities To process a case, a series of one or more activities are performed. The goal on receipt of a new case is to bring it to conclusion and it is unlikely that the case will simply "get there by itself". As such, a case has to be worked upon. For example, if a customer calls about a problem then that instance of the case will not complete itself unless some activities are performed to bring it to conclusion. Within a case type definition, we define the activities that are to be performed. These activities are defined within the case type editor within the " Activities " tab.

9 At a high level, an activity can be classified as either required or optional. Required activities are those that must be performed while optional activities are not necessarily required in order to bring the case to a conclusion. When activities are added, they show as activity icons within the appropriate grouping:

10 An activity has an implementation that must be associated with it. There are three types of possible case activity. These are: Before we go further, we need to start talking about the "state" that an activity can have.

11 Initially, all the activities of a case don't exist. In our diagram, we can consider them inactive. When a case is created, we already know about all the possible activities in that case. At this point, each activity is created and place into one of three possible states. Those states are " Waiting ", " Ready " and " Launching ". Before we discuss those, understand that an activity which a user is going to be working upon has to be in the " Working " state in order for him to see it as available to be worked upon within Process Portal. So with that in mind, let us now look back at the three initial states that an activity may have. The first we will talk about is called " Launching ". This is a transient state as an activity in the " Launching " state will very quickly and without any other conditions, transition to the " Working " state. An activity will immediately enter the " Launching " state if a case is started and the activity is flagged as being started automatically, is required and has no blocking preconditions. The " Ready " state is where a user can manually decide that the activity should be worked upon. We enter this state when the activity is flagged as being manually started and has no blocking preconditions. We can transition from the " Ready " state to the " Working " state only if a user explicitly asks that this activity be performed. The third initial state is the " Waiting " state. We enter this state when the activity is either automatic or manually started but it has blocking preconditions. The activity will stay in this state until its preconditions have been satisfied. Once satisfied, the next state will either be " Launching " because it is flagged to start automatically or will be " Ready " because it is flagged to start manually. Activities are not necessarily ready to start just because they exist. Instead, preconditions must be met before they are eligible. Let us now start to examine the different types of preconditions

12 that can be supplied. The preconditions are defined in the Preconditions tab of the properties of a selected activity. The primary aspect of a precondition is the concept of an event. This is something that has to happen before the activity can be considered eligible for starting. There are four possibilities for the event. No precondition event This is the simplest precondition. It basically states that there is in fact no precondition and that the activity is ready for starting without further events having to occur. A document is filed in the case This precondition states that a new document has to be filed within the case. The type of the document must also be supplied or an indication that any document type is valid:

13 A case property or variable is updated blah A precondition expression is met blah Case Variables An important notion of a case is the instance specific data associated with that case. Each case instance is likely to want to have information specific to that instance. For example, if a customer calls in to report a problem, the case worker will want to know the identity of the customer, the nature of the problem and other related items. The data associated with a case is defined as a set of one or more variables broken into categories of usage. The variables can be defined in the Variables

14 tab of the case editor. A screen shot of the case Variables tab is shown below: The variables can be defined in categories called " Input ", " Output ", " Private " and " Case Folder Properties ".

15 Case User Interfaces When building a case solution, we may wish to specify some screens (user interfaces) that are shown to folks working with cases at particular points. Within the Case Type definition, there is a tab called " Views " that can be used to define different screens. Each entry is associated with a Client Side Human Service that will be executed at the correct point. There are currently three UI mappings defined.

16 The Launch UI Default is the screen that is shown to a user when they start a new instance of a case through Process Portal. For example, in the following screen shot, we see an instance of Process Portal with the Start of a Case indicated. The type of this case is called " MyCase ": When the user clicks to start a new instance, the Client Side Human Service associated with the Launch UI Default is shown to the user. The output of that Human Service is anticipated to be the input to the case. Within Process Portal there is a tab called " Processes " where one can view the list of running or completed process instances. Clicking on a process brings up an IBM BPM supplied dashboard to examine that process instance. This dashboard is implemented as an IBM BPM Client Side Human Service and can be replaced by a custom dashboard. There are two choices for the dashboard that can be shown. One dashboard type can be seen by owners of the instance of the process while an optionally different dashboard type can be seen by everyone else. These dashboard screens (remember they are simply Client Side Human Services) can be named in the Details UI section.

17 Cases and their relationships to ECM It is especially common that case processing works hand in hand with documents. Quite what defines a document is very broad and open. Since we are working in IT, we should think of a document as electronic data such as word documents, PDFs, spreadsheets, s, photographs (images) and much more. Generically, we will call such documents "content". We are used to thinking of content as being housed in files but let us divorce ourselves from that idea. Instead, let us assume that content is managed by a specialized software system called an Enterprise Content Management (ECM) system. IBM BPM Advanced with basic case provides a full function ECM that is built into the BPM environment. This ECM is known as the "BPM Content Store". Because of this affinity, when an instance of a case is created, an ECM Folder is also created that can be used to house documents on behalf of the case. Think of an ECM Folder similar in nature to that of a file system folder. It is a named entity that acts as a container for documents. Within IBM BPM, the CMIS technology is used to interact with ECM systems. CMIS has the concept that every document and folder has a unique identifier. What this means to us is that when a case instance is created, although BPM causes a new folder to be mechanically created within the ECM, we don't know the "name" of that folder. Actually, we can find out its name but if we did, we would find it less than useful as it is quite technical in nature and has no relevance from and end user's perspective. However, when the case instance is created, a property associated with that case called " casefolderid " is available to us. This property is the CMIS folderid that is used to house the documents for a case. New documents for a case should be placed within that folder. We have already read that the creation of a new document of a specific type can be used as an event to create a new instance of a case, but how then does that relate to folders? We seem to have a bootstrap problem. We can't put a document in a case's specific folder until a case exists and yet we want the creation of a document to be able to create a case instance from scratch. What we seem to find is that the creation of a document used to trigger a new case instance can be placed anywhere within the ECM folder tree. When the case instance is created and the folder specific to it is created, a copy of the new document is placed in the new folder. Take care to read that carefully. What is placed in the new case folder is a copy. This means that the folder in which the document was originally created seems to also contain the original document. We also need to be careful with the nature of "copies" in ECMs. What actually happens appears to be more of the notion of linkages. When a document is created, that document exists with a unique id. When we say that a document is in a folder, what we are really saying is that the document is linked to from the object representing the folder. We can (and do) have multiple folders linking to the same document instance. As such, we need to be careful when we talk about copies because

18 what we really have is a single instance of a document and multiple links to it. This is a deviation from our simple mental model of files in a file structure where a file lives in one folder or another but can't (well it can but that's another story) live in both simultaneously. When a case instance is created, an ECM folder is also created and associated with the case. When the case completes, the ECM folder is not Case Document Types A Case Document type is a set of properties (meta data) that is associated with a document added to the BPM Content Store. From within Process Designer, new document types and their corresponding properties can be created. There appears to be "strangeness" with the naming of document types. The names seem to be being munged in unusual ways. For example, if a BPM document type called " " is created, the corresponding document type in IBM BPM Content Store is found to be "E Mail". The full rules regarding this are not yet known but in the meantime, when you create a new document type, always validate with the ECM itself what it believes the document type to be. One defines a new Document Type from the Cases catalog entry. A dialog is displayed into which the name of the new document type can be entered:

19 From here, we can add the document type specific properties: The " Property type " of the Document Type (starting to get a mouthful there) is the data type ascribed to this property. It must be a custom simple type such as a derivation of a string or integer. It may not be a Business Object nor a select value.

20 When a property on a document type is defined, we give it a name and specify the data type of that property. In addition, a property has additional attributes including: When a property is defined, it is given a display name which is the name that is shown within Process Portal. The generated Symbolic Name is the name of the attribute as reference-able via the CMIS commands if needed. If a property is removed from a Document Type, they still show within Process Portal until an administrator manually runs the command called " cleanupdocumentstoreproperties ". Case Design patterns Creating a new document within an existing case Imagine that we have received a new piece of content from a customer who already has a case instance open with us. That content may be , it may be a fax, it may be a scanned piece of paper or something else. The actual data of the content is not important to this story. What is important is that we need to direct that content to the correct case instance. Each new case instance has an associated "folder". The folder is the repository for documents associated with that instance of a case.

21 Within a folder, we can keep the documents safe. When an instance of a case is created, a case folder is automatically created within the IBM Content Store. Just like any other folder in an ECM, the folder has a unique identity called its "folder id". If we know the value of the folder id, we can then place documents within it. So how then do we get the folder id for a given case? The answer is to realize that within IBM BPM there really is no such thing as a case. That is merely an illusion. The concept of a case is actually modeled as a process. When a case instance is created, what actually happens is that a process instance is created. When the case management features were added to BPM, some additional attributes were also added to the logical notion of a process. Specifically, a process instance now has an attribute called the " casefolderid ". Bringing this all together, if we know the identity of a case, we really are saying we know the identity of a process. If we know the identity of a process, then we can lookup the attributes of that process. If we can lookup the attributes of a process, we can find the " casefolderid " value. Canceling these indirections, we can say that from the identity of a case we can get the value of its corresponding " casefolderid ". When we model a case, we can declare that the a new instance of that case will be created when a new instance of document type is created. But how then is the new document created in the first place? We can use a variety of UIs to create such document instances including Coaches. But what if we want the documents created automatically as a result of content arriving without a user interaction? We can use the CMIS functions to create such documents and use the " casefolderid " of the process/case as the folder into which it should live. If we know the identity of the case, we are now saying that we actually know the identity of the BPM process. Given a process id, we can now lookup the details of the process using: var processdetails = tw.system.findprocessinstancebyid(\<process id\>); and from there, we can access the casefolderid: var mycasefolderid = processdetails.casefolderid; Revision #1 Created 9 months ago by Admin Updated 9 months ago by Admin