Info |
---|
All cases are modeled as aggregates. However, not all aggregates are cases (an aggregate can also be used to model a register) |
ComparisonThe table below compares all DCM concepts with Blueriq concepts and briefly explains how standard Blueriq elements can be used to model the DCM concept.
Concept in DCM | Concept in Blueriq | Remarks |
---|
Image Added | Case | Image Added | Aggregate | A case is modeled as an aggregate, meaning that for each case an aggregate is defined, containing all entities necessary to define a case. See also The generic case aggregate. |
Image Added | Goal | Image Added | Decision | The goal of a case could be to grant a permit, register |
UI Text Box |
---|
|
Not all aggregates are cases (an aggregate can also be used to model a register), but all cases are aggregates. |
Comparison
The table below compares all DCM concepts with Blueriq concepts and briefly explains how standard Blueriq concepts can be used to model the DCM concept.
Concept in DCM | Concept in Blueriq | Remarks |
---|
Image Removed | Case | Image Removed | Aggregate | A case is modeled as an aggregate, meaning that for each case an aggregate is defined, containing all entities necessary to define a case. See also Designing cases using aggregates [editor]. |
Image Removed | Goal | Image Removed | Decision | The goal of a case could be to grant a permit, register an applicant, pay a benefit, sell a product etc. A goal can easily be modeled by an attribute with a default value false and a decision table or business rule which sets the attribute to true when the goal is reached. |
Image Modified | Decision | Image Modified | Decision |
The concept Decision is available in BlueriqDecisions can be modeled using attributes, default value rules, reusable expressions, decision tables, business rules, external rules and data rules. |
Image Modified | Process | Image Modified | Process |
The concept Process is available in BlueriqProcesses can be modeled using the Blueriq element process. |
Image Modified | Milestone | Image Modified | Decision | Whether a milestone is reached or not is a decision, based on the context of the case. For more information on how to model milestones in DCM applications, see Designing dynamic processes. |
Image Modified | Phase | Image Modified | Process | With phases, a case can be broken down in large concepts, using the lowest granularity. Most cases consist of five plus or minus two phases. All phases are modeled as sub processes and since processes can be modeled hierarchically within Blueriq, the main process itself, containing the phases, is modeled as a process as well. For more information on how to model phases in DCM applications, see Designing dynamic processes. |
Image Modified | State | Image Modified | Decision | A state is a characteristic of a case that tells the end user not so much about the progress of the execution of the case over time (phases are used for that), but more about the progress regarding the case's identity. For instance, a case can have the state In progress. This does not really tell us how far we are, merely to be patient. Another example of a state is Waiting for customer, when additional data or documents are needed. States can be plural on occasion, so a case could be in two states, for instance Part of spot check and Confidential. |
Image Modified | Data | Image Modified | Aggregate | For persistency of |
registersGeneric taskImage RemovedImage Added |
Process | A generic task Task | Tasks are native Blueriq elements and can be modeled as |
a task that has no precondition and is not part of a flow. For an example of a generic task, see Designing dynamic processes.such. |
Image Modified | Related case | Image Modified | Aggregate | Related cases are modeled as aggregates, just like the case itself. The relation between the related case and the |
related a (multivalued) an attribute within the related case, |
holding all 's of related casesof the main case. The type of relation (parent-child, sibling, association, etc) can also be modeled using attributes. These relation-attributes are most likely part of a Case data or Control entity, but this is the designer's choice. |
Image Modified | Risk profile | Image Modified | Decision | A risk profile or risk calculation can be performed with decisions and sub-decisions perfectly, using potentially many attributes of the case. |
Image Modified | Note | Image Modified | Dashboard Comment container | Notes are |
similar to generic tasks and could be as such (in combination multivalued attribute), but within Blueriq the dashboard dashboard comment container |
can also be used for comments. By default, the comments are multivalued and date-time and user are stored alongside the comment |
(toch? en in welke case entiteit slaan we de notes op? case metadata?).. If so desired, notes can be modeled with attributes of a Note entity, most likely when it is necessary to store more information alongside the note or when the note is typed (for instance Comment, Internal, etc.) |
Image Added | Appointment | Image Added | Attribute(s) | To model an appointment within a case, the best |
Image Removed | Appointment | Image Removed | Attribute(s) | To model an appointment within a case, the best fit is to use attributes of an Appointment or Control entity. For the integration with a calender (for instance Google calender or Outlook), tailored software has to be bought or developed, since this is not available in Blueriq out-of-the-box. |
Image Modified | Event | Image Modified | Incoming external message | Events are situations form outside the case that require actions to be taken withing the case. For instance the death of the applicant could require the case to cancel, or the divorce of an applicant could result in recalculation of a fee. In Blueriq, events are modeled as in incoming external messages. For an example of an incoming external message, see Designing dynamic processes. |
Image Modified | Document input | Image Modified | File upload container | File management is an integral part of Blueriq. Containers are available to upload and download documents to memory or the file system. Documents that are input for the case and need to be uploaded within the case, use the file upload container for that. |
Image Modified | Document output | Image Modified | Document |
The concept Output document is available in BlueriqOutput document can be modeled using document elements. |
Image Modified | Involvement | Image Modified | Attribute(s) | Involving persons |
or roles in a case is not part of standard Blueriq functionality, but can easily be modeled using one or more (multivalued) attributes, most likely as part of an Involvement entity, but this is up to the designer. To involve someone in a case, for instance the |
civilian a the case handler or investigator, means setting an attribute with the desired involvement. |
Image Modified | Team | Image Modified | Team |
The concept available in a native Blueriq element. |
Image Modified | Organization | Image Modified | Attribute(s) | Organizations strongly resemble teams, but |
the concept an organization element itself is not available in Blueriq by default. Therefore, organizations can be modeled using one or more (multivalued) attributes, most likely part of an Organization entity, but this is up to the designer. To rout a case to an organization, means setting an attribute with the desired organization. |
Image Modified | Role | Image Modified | Role |
The concept available in a native Blueriq element. |
Image Modified | Time management | Image Modified | Time management |
The concept Time management is available |
in Blueriq.Image Removed | History | Image Removed | Time line container | by default in Blueriq, amongst others by means of (ad-hoc) timer nodes and the due date of tasks. |
Image Added | History | Image Added | Time line container | History can be modeled |
The concept History is available in Blueriq by means of a time line container. |
Anchor |
---|
| The generic case aggregate |
---|
| The generic case aggregate |
---|
|
The generic case aggregate
Since all cases can be modeled as aggregates, one might wonder what such an aggregate would look like. Are they completely different for each case or is there a common ground among all cases? The answer is the latter; aggregates that resemble cases all look alike. Shown below is the outline of such a generic case aggregate.
UI Text Box |
type Info |
---|
The When modeling a DCM solution with Blueriq, the use of this generic design of the generic a case aggregate as shown above is not mandatory, but strongly advised. It strongly advised, just as the use of the DCM foundation library (DCM Foundation). The generic case aggregate is based on designs used in several projects, proof of concepts and demos and has proven to be successful thus far. It is suitable in government, insurance and financial domain where law and legislation play a pivotal role. |
Entities in the case aggregate
The table below briefly explains each entity within the generic case aggregate.
Image Modified Entity | Explanation |
---|
Case data | All data that is relevant within the case can be part of this entity. For example, in a case |
with for an application for a permit to extend a house, all attributes |
about the applicant, the address house part of the entity, but also data, as well as the case handlers |
as well as can be modeled within this entity. |
Case metadata | All metadata of a case can be combined in this entity. Example attributes are |
(tja, noem er eens eentje die niet hieronder verder voorkomt)creation date, archive date, type, Id etc. |
Precondition | Activities in a dynamic case are not modeled as part of a flow with gateways and arrows, but as ad hoc tasks with preconditions that tell when the activities may be performed (see also Designing dynamic processes). For purposes of understandability, insight and oversight, it is best to combine all preconditions of a case and make them part of one entity. |
Milestone | For each phase within the case, a milestone tells whether the phase is complete and the next phase may begin. This entity contains an attribute for each milestone. |
Primary Decision | The primary decisions of a case can be combined in this entity. Examples are whether an application is complete or granted, or whether a spot check needs to be performed etc. The goal of a case will most likely be part of this entity as well. |
Time management | Time management or time monitoring can be part of the case when there are legal and/or legislative terms which must be complied with, such as a maximum amount of time in which an application has to be handled. Attributes used in this entity could be the terms themselves, but also the actual time that was needed. |
Risk profile | A risk profile entity can be used when a certain permit, benefit or insurance may not be granted unconditionally, but is subject to for instance an audit or a two-men-rule, should the application pose a risk. Risk calculation could then be done using attributes throughout the case, the (intermediate results and) final result of such calculations should be part of this entity. |
Norm | Norms are guidelines that are administered by law. People have to abide to the law, so they have to abide to or comply with the norms that are set within the law. For example, in an application case for a permit to extend a house, one has to comply with the norm that states that the additional surface of the extension is not more than a certain percentage of the surface of the original house. |
Ground | Grounds are usually intermediate results, decided or calculated because of specific articles of the law. Examples are the ground for tax on employment income, franchises or calculated income on which pension is based. But also the surface of the intended extension of a house (as mentioned in the previous row) could be regarded as a ground and can be used to test whether a norm is complied with or not. |
Constant | When there are constants in the domain of the case, it could be the designer's choice to explicitly model them as attributes of a constant entity. An example of such a constant could be the percentage that is used as a maximum regarding building extensions (as mentioned in the two previous rows). For more information regarding constants, see the chapter Constants of the Decision Management guide. |
Document | With file management, it is advised to use a multiton (non-singleton) entity to create an instance for each document that is part of the application or the case. Such an entity contains metadata attributes like name, size, type, creationdate, etc. |
Involvement | Involvements are modeled by means of a multiton entity, possibly containing attributes such as Id, role and name and from when to when (phase or date) someone was involved in the case. |
Organization | When organizations are part of the case, the routing behavior as available for teams must be mimicked for organizations using this multiton entity. Additional tailored software needs to be developed to integrate teams in Blueriq's out-of-the-box routing mechanism. |
Appointment | When appointments are part of the case, this multiton entity can be used to create multiple appointment instances. Possible attributes concern who wants to make an appointment with whom, when, where and why. Additional tailored software needs to be developed or bought to integrate appointments with a calender application such as Google calender or Outlook in runtime. |
Control | This entity contains steering attributes, such as ProcessId, CaseId, TaskId. |
Info |
---|
If a project contains more than one case, all entities of the table above need to be duplicated |
and prefixed or postfixed (for instance with the case name) to avoid confusion. This means there could be an entity named Application_Document alongside Complaint_Document (or if you prefer Document_Application and Document_Complaint). (toch?). It is preferred to create different projects for different cases, rather than prefixing or postfixing all entities (like Document_Application and Document_Complaint). |
Relation between cases
When a case is related to another case, the related case "knows" with which case it is related, but not the other way around. The main case may use the result of the related cases, so related cases contribute to the main case. Furthermore, the fact that the main case does not know its related cases is also due to the fact that such related cases may come into existence after the main case is long closed. So a complaint case will contain the Id of the related application case (as part of the complaint case entity Case data), but the application case will not contain all Id's of the complaints that are related to it. Lists can be used in Blueriq to navigate from a main case into its related cases.
Characteristics of a case
As discussed in this article, a case the universe of Dynamic Case Management is more than just a process. Two other very important dimensions play a role in a case, namely Rules and the Case context. This is shown in the diagram below.
Image Added
A case in a Dynamic Case Management design contains three main dimensions: Process, Rules and Case context. The Process is a set of activities that can or must be performed in order to reach a certain goal, for instance a payment, a permit or a benefit. The process in a dynamic case is not modeled with a predefined order in mind, using arrows. It contains independent activities, each with a precondition that states when the activity is relevant. These preconditions are Rules that use the Case context. This Case context is extended by input by users or services by means of activities of that process.
See also
More information on how to design dynamic processes in Blueriq can be found here: Designing dynamic processes.
Everything about persistency management and aggregates can be found here: Persistency Management guide.
A visualization of most concepts discussed in this article can be found here: Blueriq visuals.
A template for dynamic case management can be found here: DCM Foundation - v4 [editor] .
Specifically for dynamic case management and persistency management, see
1 Case
In Blueriq a case is defined as an instance of a process. With the adoption of DCM and DCM's definition of a case as described in this document, there are two definitions of case present in the Blueriq Community documentation. At the moment, we are rectifying this.
Relation between cases
Hier moet ik og iets zeggen over de impliciete relaties (Id van de gerelateerde case opslaan in "deze" case en in de goeie volgorde opslaan en ophalen)
See also
More information on how to design dynamic processes in Blueriq can be found here: Designing dynamic processes.
Everything about persistency management and aggregates can be found here: Persistency Management guide.
A visualization of most concepts discussed in this article can be found here: Blueriq visuals.
Specifically for dynamic case management and persistency management, see
Dynamic case management
Dynamic Case Management | Persistency management
Aggregate