Mohammed Atef’s Technical blog

ICM Repeated DB Execute for any task steps


In our real world we always found new needs that cannot done easily throw out-of-the-box tools. Currently I am using IBM Case Manager for delivering Automation solution, but I realized that our solution needs a custom database, during discussing with my technical colleagues, we came up with the following solution and now I am sharing this with you.

Use case

You are working in a new IBM Case Manager solution, and you have to log some case properties details in custom SQL Database for each and every step, you can do this regularly by calling stub step after each and every step, but this solution with complex your tasks design.
I am going to share with you another solution to do same requirements with better and simple solution.


Our solution is simply built on creating an automatic task (dbexec) that run with precondition based on case property value, this task actually used to run the DB Execute system step. Other task steps will set specific case property to trigger the dbexec task.


Let go throw this solution in more details.

Procedure 1: Create the solution, case and tasks

1- Open Case Manager Builder from the browser, and login with valid user name and password.

2- Create solution name loans, then create the following properties (Loan Name, tmpstepid) and create role named loan manager

3- Create case named Loan DB Exec and modify the tmpstepid property to be hidden from properties, then add both properties to the case properties.

4- Create new automatic tasks named Main Task , and another automatic tasks named dbexec but with condition and repeated as shown in the following pictures


Procedure 2: Design tasks

1- Open the main task designer and drag Role Lane then add three steps names (step1, step2, complete) to it.

2- Assign the two case properties for each step, then draw the connectors between launch Step and other three steps as shown below


3- Open dbexec designer and drag Role Lane then add step to it, after that add another stub step to the system Lane and draw connectors as follows


Procedure 3: Prepare SQL table and procedure

1- Here we are going to create the SQL table and stored procedure that needs to execute for each and every step in the Main Task2.

2- Below SQL scripts shows how to create both of them:

   1: CREATE TABLE [dbo].[loans](
   2:     [stepid] [nchar](10) NULL,
   3:     [loanname] [nvarchar](50) NULL
   4: ) ON [PRIMARY]
   6: create PROCEDURE [dbo].[sp_addloan]
   7:         @loanname varchar(100) output
   8:     ,@stepid varchar(100) output    
   9: AS
  10: BEGIN
  11: insert into loans values(@loanname,@stepid)    
  12:     END
  13: GO

Procedure 4: Modify the main task from Process Designer

1- In Workplace XT, click Tools > Advanced tools > Process Designer.

2- Click File > Solution > Edit > case_manager_design_object_store_name > IBM Case Manager > Solutions > Loans > Solution Definition

3- Open the Main Task and Assign the tmpstepid property after or before execution for each step as follows


3- task care you have to assign different value for each step to launch the DBexec task

Procedure 5: Modify the DBexec from Process Designer

1- Open the dbexec task in designer as shown in procedure 4, steps 1 & 2

2- Configure the DBexecute step

3- Select the Route between the Stub and Dummy step and modify it to be a conditional  Route the in the expression space enter the following line 1=2, as shown below:


4- Yes you are right this condition will never happen and the task will ends after the Db execution.

Procedure 6: Deploy and test the solution

1- From Process Designer Check in the solution

2- Open Case Manager Builder and deploy the solution

3- Open Case Manager Client and create new case from Loan Db Exec

4- Go throw step1, step2 and complete steps.

5- Open the database and you will find three records in you custom table.


In this post we have seen how to run repeated DB execute task for each step in other tasks. This solution may be used in other ways for different requirements for example you can use it to send email instead of executing DB. i hope that help.


before ending this post i would like to thank Mr. ahmed Elwakeel my dear colleague who worked with me to implement this solution.

March 1, 2013 Posted by | Uncategorized | , , , , , , , | 9 Comments

BPM and Business Processes

Hi All, I have been read a very good white paper about BPM(Business Process management) really I understood a lot about how to use Microsoft technologies to improve you business process.

I have summarized this white paper to you and i would like to be used for you.

First i want to describe BPM .What is business process management (BPM)? To business people, BPM means viewing an organization as a set of processes that can be defined, managed, and optimized. Rather than focusing on traditional departmental silos, such as finance, marketing, and manufacturing. To technical people, it most often refers to a group of technologies focused on defining, executing, and monitoring process logic. Despite their different perspectives, both groups have the same goal: making business processes better.

Microsoft has a range of offerings that fall under the umbrella of BPM technology. For Microsoft’s customers, these technologies can provide direct solutions to process problems. For independent software vendors (ISVs), Microsoft’s BPM technologies act as a platform for building more specialized solutions.

The Goal: Better Business Processes

As with any technology, BPM isn’t a goal in itself. Instead, organizations use BPM to improve their business processes. BPM technologies can make processes faster, letting businesses be more responsive to their customers. They can also make those processes more reliable, more consistent, and less error-prone. In a very real sense, business processes are the business, and so making them better is a clear path to improving the business itself.

Even though different organizations use quite different processes, there’s still a great deal of commonality across different businesses. For example, many processes depend on a group of people working together to perform a defined group of tasks. Writing a proposal fits this model, for example, as does approving a document and many other business processes. It’s also common for processes to depend on different kinds of software working together, usually in a quite structured way. This software can make decisions, ranging from choosing among simple options to making complex rule-based choices. Monitoring running processes is also useful, as is having some way to describe those processes. These similarities across different organizations are what make BPM technology possible. By extracting the common elements of business processes, then implementing automated support for this commonality, BPM technologies offer a generally useful approach for process improvement.

Reaching the Goal: BPM Technologies

As with the definition of BPM itself, reasonable people can disagree about exactly which technologies should be included under this heading. Still, there’s broad consensus that the essentials include the following:

1- Technologies for defining and executing human workflows, which are processes that connect people. Providing automated support for human-oriented processes is a fundamental aspect of BPM, as are the graphical tools used to define those processes.

2- Technologies for defining and executing system workflows, which are processes that connect software. Supporting these automated interactions among applications is another fundamental part of BPM, and it again includes graphical tools to define those interactions. Integration technologies are often included here as well, such as adapters for connecting to diverse systems and tools for defining data transformations. The ability to combine human and system workflows is also important, since many business processes involve both.

3- Business rules engines (BREs). If decisions made by a business process can be expressed as a set of rules, a BRE can frequently be used to make those decisions in software. Doing this can help decision making be faster, cheaper, and more consistent.

4- Business activity monitoring (BAM). The people who rely on a business process can often benefit from visibility into currently running instances of that process. BAM provides this visibility, exposing relevant information about running processes in terms that are meaningful to the information workers who use it.

5- Process description tools: Having a clear understanding of a business process commonly starts with a picture of that process. Graphical tools for illustrating the actions and relationships in a process are useful for creating this picture.

Microsoft’s primary BPM technologies fit quite well into these five categories. Those technologies are the following:

1- Human workflow: Windows SharePoint Services and Office SharePoint Server.

2- System workflow: BizTalk Server, which provides integration services as well. It can also be used with Windows SharePoint Services and other products to create combined human and system workflows.

3- Business rules engine: BizTalk Server’s BRE. Microsoft also provides a rules engine with Windows Workflow Foundation, part of the .NET Framework 3.0.

4- Business activity monitoring: BizTalk Server’s BAM, together with technologies such as Microsoft Excel and Office PerformancePoint Server for displaying BAM information.

5- Process description tools: Microsoft Visio.

Connecting People: Human Workflow

Human workflow is applicable to many different business processes. Document approval is the most common in many organizations, but more complex scenarios are also in widespread use. Whatever it’s used for, the fundamental technology required is much the same.

Human Workflow with Windows SharePoint Services and Office SharePoint Server 2007

 The latest release of Windows SharePoint Services, Microsoft’s flagship collaboration software, includes built-in support for executing human workflows. Developers can create workflows for this environment using Visual Studio, while information workers can use a new tool called SharePoint Designer 2007. Microsoft Office SharePoint Server 2007, part of the 2007 Microsoft Office system, builds on the basic capabilities of Windows SharePoint Services, adding pre-defined workflows and more. This section provides an overview of these technologies.

The easiest way to understand how Windows SharePoint Services supports human workflow is to walk through a scenario. The figure below shows a slightly simplified illustration of document approval using a SharePoint workflow.


In this example, the workflow allows a number of participants to approve or reject a document stored in a document library. To start this workflow, the initiator uses Internet Explorer or another Web browser to select the document, then chooses an existing workflow definition to execute (step 1). Workflows can also be started automatically, such as by adding a new document to a document library.

To let workflow participants know that they have something to do, the workflow adds a task to each participant’s task list (step 2). This task list is just an ordinary SharePoint list. Each participant then checks his or her task list using a Web browser or Microsoft Outlook 2007 (step 3), and finds a request to review this document. Each participant can review the document (step 4), then interact directly with the running workflow through a custom form to indicate approval or rejection (step 5), perhaps adding comments. Once all of the workflow’s participants have done this, the workflow informs the initiator that it’s done.

Connecting Software: System Workflow

Now commonly viewed as part of BPM, improving business processes by connecting the software that supports them is a familiar idea. Distinguishing this kind of system workflow from human workflow is useful, as the requirements and the exact problems to be solved are different. Human workflow requires interacting with people through task lists and forms. System workflow requires interacting with software through adapters and data translations, and it typically implements more stable processes. Even though supporting an end-to-end business process can require human and system workflow.

Connecting software is often divided into enterprise application integration, which typically refers to connecting software within an organization, and business-to-business integration, which focuses on connecting software in different organizations. Both categories can be seen as part of the larger grouping of business process automation. Whatever terms are used, the goal is always the same: better business processes.

System workflow can improve a business in a number of ways. Automating existing manual work can make processes faster and more accurate. Synchronizing information across different applications can ensure that everybody sees the same view of customers, patients, or anything else this organization works with. Automating links between organizations, such as with electronic data interchange (EDI), can significantly improve the reliability of ordering, payment, and other cross-organizational exchanges. All of these process improvements rely on integration technologies, and all can be driven by system workflow.
System Workflow with BizTalk Server

The primary Microsoft technology for system workflow and integration is BizTalk Server 2006. Along with tools for defining workflow logic and runtime support for executing it, the product includes several other BPM technologies. This section looks at the aspects of BizTalk Server that are most directly related to system workflow.
As before, a simple scenario is the best way to make clear how BizTalk Server supports system workflow. The figure below shows an example of how an organization might use this product to automate the process of placing an order.



The system workflow itself—the logic that controls this process—is implemented in a BizTalk orchestration, as shown above. Because different applications represent information in different ways, BizTalk Server also provides data transformation tools to map between these diverse data formats. And since a variety of approaches are used to communicate with applications, BizTalk Server relies on adapters to implement different options. The product includes adapters for communication via queues, via Web services, through the Windows file system, and using other technologies. Microsoft also provides adapters for interacting with popular packaged applications, such as those from SAP and Oracle.

In this example, suppose an inventory application determines that some item needs to be reordered. It sends an order request to BizTalk Server via an appropriate adapter (step 1). This request starts an orchestration, which then creates a message requesting a purchase order (PO) for this new item and sends it to this organization’s ERP application (step 2). As always, communication between BizTalk Server and this application relies on some adapter, and BizTalk Server also performs any required data transformation. Next, the ERP application creates the purchase order and sends it back to BizTalk Server (step 3). Once this message is received, the orchestration creates another message to actually place the order, then sends it to the fulfillment application (step 4).

All three of the applications used in this process might be inside the same organization, making this an example of enterprise application integration. It’s also possible that, say, the fulfillment application is located at a supplier firm, which makes that part of the process qualify as business-to-business integration. In either case, the system workflow implements the controlling logic for this process, while each of the applications the workflow relies on carries out its own responsibilities.

Connecting software with system workflow commonly involves dealing with a significant amount of technology. Because of this, the primary tool BizTalk Server provides for creating system workflows targets developers. Hosted inside Visual Studio, the Orchestration Designer lets developers define system workflows by dragging and dropping actions (called shapes) onto a surface, much like the developer tool used with Windows SharePoint Services. The screen shot below shows how this looks.


Along with this developer-focused tool, BizTalk Server also provides a Visio-hosted design tool. Called the Orchestration Designer for Business Analysts, it’s aimed at less technically oriented people. Orchestrations created with this tool can be imported into the Visual Studio-hosted tool shown above. A business analyst might define the process used in a system workflow, for example, then pass this definition to a developer. The developer can then add the technical details required to make the orchestration executable.

Windows Workflow Foundation

Given this similarity, it makes sense to create a common workflow engine that can be used for any workflow-based application. This is exactly what Microsoft has done with Windows Workflow Foundation (WF). Targeted strictly at software developers rather than business analysts, WF is intended to be used for any kind of workflow-based application. It provides a workflow engine, a standard set of activities for defining workflows, and a graphical designer to help developers create workflows and their own custom activities.

Just as important is what WF does not provide: direct support for human workflow, such as task lists or forms creation, or direct support for system workflow, such as adapters and data transformation. WF is solely focused on defining and executing the workflow logic itself, and it’s meant to be useful for both human and system workflow.

Similarly, a future release of BizTalk Server will implement system workflows (i.e., orchestrations) using WF (although existing orchestrations will still be supported). The WF workflow designer is also planned to supplant the product’s current Orchestration Designer. Rather than implement and support multiple workflow engines, Microsoft has chosen to use WF as a common foundation in most of its future products that implement workflow.

Using Human and System Workflow Together
From a technical perspective, human workflow and system workflow are different in important ways. From a business perspective, however, improving a business process might require using both approaches. Accordingly, it must be possible to use both technologies together.
For example, some orders in the process just described might require human approval. Does it really make sense to let software decide to spend what could be a large amount of money? If the expense is high enough, placing an order might even require approval from several people. The process of making this decision could be implemented using a human workflow, which means that the entire business process would rely on a combination of system and human workflow. This section describes how this can be done in the Microsoft world.


Microsoft’s foundation solution for human workflow is Windows SharePoint Services, while BizTalk Server plays that role for system workflow. It shouldn’t be surprising that these technologies can be used together to implement a process combining human and system workflow. The figure below shows a simple example of how this might look.


The first three steps in this scenario are the same as in the system workflow example shown earlier: the inventory application sends an order request to BizTalk Server (step 1), and BizTalk Server requests (step 2) and receives (step 3) a purchase order from the ERP application. Now, however, let’s assume that the PO amount is sufficient to require approval from a group of managers at this firm. A human workflow implemented using Windows SharePoint Services is used to make this decision.

Once the orchestration has determined that this PO requires managerial approval, it uses a SharePoint adapter to add a document to a particular document library (step 4). As mentioned earlier, adding a new document to a library can automatically trigger execution of a SharePoint workflow, which is exactly what happens here. This workflow then executes as described earlier, adding tasks to the participants’ task lists. Each participant approves or rejects the order (step 5), and once all responses are in, the workflow adds information to the document previously created in this document library by the orchestration, an action not shown in this figure. BizTalk Server’s SharePoint adapter retrieves this modified document, something that’s also not shown, and if the order is approved, contacts the fulfillment application to place it (step 6).

Combining human and system workflow is the right approach for improving a number of business processes. As this example shows, Windows SharePoint Services and BizTalk Server can be used together to accomplish this. Two distinct workflows must be defined, using two different design tools, and those workflows will be executed by two separate workflow engines. Still, this combination can be used for business processes that require both kinds of workflow.

Ascentn AgilePoint, built on the .NET Framework and other Windows technologies, is focused entirely on human workflow. Accordingly, the product relies on BizTalk Server for system workflow and integration. As the screen shot below illustrates, Ascentn’s Visio-based tool for defining processes, called Envision, can include a BizTalk orchestration directly within an AgilePoint workflow. While the orchestration’s logic can’t be modified in this tool, it is possible to define BizTalk endpoints and configure the orchestration in other ways.

For business processes that need both system and human workflow, combining BizTalk Server with AgilePoint in this way can make sense. While BizTalk Server addresses the system workflow and integration aspects of the problem, AgilePoint offers support for human workflow that goes beyond what’s possible with Windows SharePoint Services. Among the things this product provides, for example, are the ability to add new participants in new roles while a workflow is running and to display different forms based on a participant’s role.

Automating Complex Decisions: Business Rules Engines
Making good decisions quickly is the essence of an effective business. Software has always been good at simple if/then choices, but more complex decisions have traditionally been left up to people. This tradition is changing, however, with the increasing use of business rules engines (BREs).
Like other BPM technologies, BREs potentially offer a number of benefits. Decision making can be faster, since it can be done by software rather than people, and it can be more consistent, adhering to the same set of rules every time.BREs can make rules easier to change and to share across different applications. In some situations, it’s even possible to let business people directly define and update these rules. While a BRE isn’t the right technology for every situation, it nonetheless can be useful for improving a variety of business processes.


The BizTalk Server Business Rules Engine

Microsoft’s most widely used BRE today is provided as part of BizTalk Server. Despite how it’s packaged, this BRE can be used either with a BizTalk orchestration or with any .NET application. To see how this technology might be used, think once again about the combined human and system workflow scenario shown earlier. In that example, BizTalk Server provided the system workflow and integration services that connected diverse applications, but the decision about whether to place high-value orders was made by people interacting via a Windows SharePoint Services workflow. It might be possible, however, to formalize the rules used to make this decision, then store them in the BizTalk Server BRE. Rather than relying on people, this business process could be implemented entirely in software. The figure below shows how this would look.

As the figure illustrates, the first three steps remain the same as in the previous scenarios. The decision to approve or reject a high-value order, however, is made by the BizTalk Server BRE (step 4) rather than by people. The BRE is invoked directly from the running orchestration, returning the result of its evaluation. As before, the order is then placed only if it was approved (step 5). If the rules underlying this decision can be expressed objectively and accurately, the benefit to the business process is clear: decision making will be faster and more consistent. It might also be more transparent, since the rules are now available in an external format—they’re no longer stored solely in people’s heads.


As this example shows, a BRE might be able to replace decisions made by people in a business process. It’s also possible for a process to use both decision-making approaches. In the example shown here, for instance, suppose that the decision criteria for some kinds of orders can’t be completely captured in formalized rules. It’s possible that along with the steps shown above, the process would also include a human workflow, perhaps implemented using Windows SharePoint Services. While a BRE might sometimes replace decisions made by people, the two can also be used together.

Rules in Windows Workflow Foundation

Along with the BRE in BizTalk Server, Microsoft also provides a rules engine with Windows Workflow Foundation. The approach taken by the WF engine is somewhat different from that of the BizTalk Server BRE. For example, the BRE uses the powerful but harder to understand Rete algorithm, while the WF rules engine relies on a simpler approach that’s meant to be easier to use. Given that it’s part of the .NET Framework 3.0, it’s fair to characterize the WF rules engine as a developer-focused technology, and so Microsoft has tried to make it more approachable by typical Windows developers.


This is the rationale behind RuleBurst’s approach to working with business rules. Using the company’s products, an information worker can create rules in Microsoft Word, Microsoft Excel, or Microsoft Visio. As the Word example below shows, these rules are created in something quite close to natural language, helping business people more easily create and modify them.

Once a set of rules is defined in this way, it can be imported into RuleBurst Studio, a tool that targets developers, then compiled into the format required by the BizTalk BRE. RuleBurst also provides tools that help rule creators test rule sets, search them, and more. All of these have the same intent: provide a more business-friendly approach to working with rules.

While RuleBurst offers tools for the BizTalk BRE, InRule provides tools that let business users and developers create rules for the WF rules engine. The screen shot below shows the rule authoring tool for the company’s InRule for Windows Workflow Foundation. As this example shows, rules can be expressed in language that’s reasonably close to normal speech, allowing non-specialists to work with rules technology.


Tracking Business Processes: Business Activity Monitoring

Automating a business process can bring clear benefits. Yet compared to one performed by people, an automated process is typically quite opaque; getting information about the status of a process can be challenging. The goal of business activity monitoring (BAM) is to provide visibility into automated processes, offering useful real-time information to the people who rely on those processes.


It’s useful to think of BAM technology in two distinct parts:

1-    Infrastructure for collecting information about in-progress business processes. Because these processes might rely on multiple applications, this infrastructure must be usable with more than just a single workflow technology.

2-    Tools that let information workers access that information. Different people will want to use BAM data in different ways, and so the tools they use might be quite diverse. Some typical examples include dashboards that provide real-time display of critical data, reporting services that present historical trends, and common desktop tools such as spreadsheet applications.

Since the technology required for BAM crosses diverse areas, it shouldn’t be surprising that it involves a number of different Microsoft products. Those products can be grouped into the two categories just described:

1-    Infrastructure for collecting information about running processes. This technology is licensed as part of BizTalk Server. Like the BRE, however, the BAM infrastructure can be used with both BizTalk orchestrations and any application built on the .NET Framework.

2-    Tools that let information workers access that information. Whatever application the BAM data comes from, it’s always stored in a SQL Server database, typically in a multi-dimensional cube. This means that any tool capable of working with SQL Server cubes can access and display BAM data. The most important of these for BAM include Microsoft Excel, Office PerformancePoint Server, BizTalk Server’s BAM Portal, and SQL Server Reporting Services. Other Microsoft products can also be used, such as Visio, as can products from other vendors.

The figure below gives a simple view of BAM in the Microsoft world, showing the fundamental technologies in both of these categories.

As the figure shows, BizTalk orchestrations can directly generate BAM events and data, all of which are sent into a common BAM database. BizTalk Server also includes a tool called the Tracking Profile Editor that lets a developer configure an orchestration to send the desired information to this database. Along with built-in support for using BAM with orchestrations, BizTalk Server also provides a BAM client API that can be used with any .NET application. (No BizTalk Server license is required for applications that use this BAM API.) In the example shown above, for instance, the BAM API is used by two other applications to send data to the BAM database. The product’s next release, BizTalk Server 2006 R2, will add built-in support for using BAM with applications built on Windows Communication Foundation or Windows Workflow Foundation. Although this forthcoming WF support for BAM isn’t usable with human workflows built on Windows SharePoint Services, it is possible to use the standard BAM client API with custom SharePoint workflows.

However it gets to the BAM database, data is always stored in tables and cubes. Cubes are most commonly used in data warehouses, and so they’re typically seen as a business intelligence technology. Yet BAM can also be viewed in this light: It’s real-time business intelligence. The information in the cubes is accessible via a set of BAM web services, as shown in the figure, and different clients are free to do different things with this information. An Excel user, for instance, might read it into a pivot table, then create a graphical view of the aspects of this process that she wishes to see. This view can be updated as often as necessary, allowing real-time monitoring of the business process.

Other tools can display the data in other ways. Office PerformancePoint Server, for example, might display BAM data generated by one or more business processes as part of a dashboard. The screen shot below shows an illustration of how this might look using PerformancePoint’s Business Scorecard Manager.



Describing Business Processes
As a process-oriented perspective continues to grow in enterprises, the ability to describe those processes matters more and more. Business people need to understand the processes their organization relies on, and they need to communicate those processes clearly to the IT people who implement them. The IT staff also needs to have an accurate big-picture view of what their organization is asking them to do. Tools for visualizing business processes can help.

Microsoft Visio is today’s most widely used tool for describing business processes. While it can be used for many kinds of drawing—it’s not solely a process modeling tool—Visio is nevertheless a common choice for this purpose. The product provides shapes for describing processes using the Business Process Modeling Notation (BPMN), and it also includes its own shapes for doing this, as the screen shot below shows.


However it’s done, accurately describing a business process is an important step in improving it. Visio is perhaps today’s most widely used general-purpose drawing tool, and so it’s not surprising that this popularity extends to documenting business processes.  


BPM has gone mainstream. As its technologies continue to spread, more and more organizations will use them to make business processes faster, less error-prone, and more reliable. Even in companies whose business leaders haven’t embraced a process-oriented perspective, BPM technologies can provide significant value in a variety of IT projects.

February 9, 2009 Posted by | Architucture | | Leave a comment