If the K2 Studio Designer toolbar is not shown by default, using the Visual Studio menu, navigate to View

Figure 9.3. Figure 9-3

The following table describes the buttons that make up the K2 Studio Designer toolbar.

Button	Name	Description
	Align to Grid	Aligns the selected items to the grid.
	Align Lefts	Aligns the selected items to the left.
	Align Rights	Aligns the selected items to the right.
	Align Bottoms	Aligns the selected items to the bottom of the grid.
	Align Tops	Aligns the selected items to the top of the grid.
	Center Horizontally	Centers the selected items horizontally.
	Center Vertically	Centers the selected items vertically.
	Decrease Horizontal Spacing	Decreases the horizontal spacing between the selected items.
	Increase Horizontal Spacing	Increases the horizontal spacing between the selected items.
	Decrease Vertical Spacing	Decreases the vertical spacing between the selected items.
	Increase Vertical Spacing	Increases the vertical spacing between the selected items.
	Make Same Size	Alters the size of the selected items so that they are all the same size.
	Make Same Height	Alters the height of the selected items so that they are all the same height.
	Make Same Width	Alters the width of the selected items so that they are all the same width.
	View Code	Shows the XML version of the process .kprx file.
	Lock Controls	Locks the selected objects on the design canvas.
	Toggle Line Mode	Switches drawing mode from selection to line drawing. Line drawing can also be accomplished by alternate-click drawing.
	Collect Copy	Copies an image to the clipboard of items that are selected using a selection box.
	Connect Activities	Connects the selected activities with Line Rules.
	Deploy	Builds the process and starts the Deploy Project Wizard.

The K2 Object Browser displays K2 objects and user-defined objects available to the developer during the development process. These objects include third-party line-of-business (LOB) systems or K2 Objects created by the developers. The K2 Object Browser is shown in Figure 9-4.

Figure 9.4. Figure 9-4

The following table describes the tabs contained by the K2 Object Browser:

The Environment Browser

The Environment Browser is used to manage the servers and services that host the K2 Platform resources. A default development environment is used to populate with the desired servers and services used during the development phase. Additional environments can be created that represent the other physical environments, for example, staging and production. This makes it simple to switch between the different environments. Figure 9-5 shows the Environment Browser.

Figure 9.5. Figure 9-5

The following table describes the servers and services contained in the Environment Browser:

Server/Services	Description
Category Server	Provides the hierarchical system for deploying processes and SmartObjects as well as for categorizing reports and notifications.
Mail Server	The mail server(s) used by the environment to send e-mail notifications.
SharePoint Server	The SharePoint(s) server used by the environment. The SharePoint server node can be expanded to display the lists, document libraries, and so on as subnodes.
SmartObject Server	Displays the SmartObjects from the SmartObject server and the local environment. The SmartObject nodes can be expanded to display their methods as subnodes.
Workflow Web Service	Displays the Workflow Web Service(s) connection details.
Workflow Management Server	Displays the Workflow Management Server(s) connection details.
Workflow Server	Displays the Workflow Server(s) connection details.

To toggle between the environments click on the downward arrow next to the tab name, in this case Environment (Development). Select Environments, which expands to a submenu that lists all of the available environments. Select the desired environment.

The User Browser

The User Browser exposes all of the Active Directory Users and Groups. While the default provider is Active Directory, other options exist. One that is simple to use is the SQL User Manager. It is installed when K2 blackpearl is configured in the form of a database called K2SQLUM. It is permissible to edit the data within this database to set up your users and groups. The provider used to connect to the User Browser is also extendable allowing developers to create a custom user provider. This is useful should you want to connect to a LOB system that manages your users. The User Browser is shown in Figure 9-6.

Figure 9.6. Figure 9-6

The following table describes the contents of the User Browser:

User	Description
Roles	K2 Roles (defined in the K2 Management Console)
Users	Active Directory Users
Groups	Active Directory Groups

The Process/Activity Data Browser

The Process/Activity Browser exposes all of the data fields and XML Fields that have been defined for the processes and activities. It also exposes the SmartObject Associations and References. Figure 9-7 shows the Process/Activity Data Browser.

Figure 9.7. Figure 9-7

The following table describes the contents of the Process/Activity Data Browser in more detail:

Data	Description
Data Fields	Data Fields contain custom information related to an activity or process. The activities and processes are displayed as nodes, which in turn can be expanded to display the data fields as subnodes.
XML Fields	XML Fields contain custom XML nodes related to an activity or process. The activities and processes are displayed as nodes, which can be expanded to display the XML fields as subnodes.
Associations	Associations provide the mapping between SmartObject properties and process data fields.
References	Provides a way to add references to SmartObject methods to more easily use SmartObject properties throughout the design of the process.

To add new data fields, right-click the desired Activity, Process, Associations, or References node, and select Add.

The Workflow Context Browser

The Workflow Context Browser exposes the workflow instance related fields, as shown in Figure 9-8.

Figure 9.8. Figure 9-8

The following table describes the contents of the Workflow Context Browser in more detail:

Instance	Description
Process	Displays the process instance properties as subnodes.
Activity	Displays the activity instance properties as subnodes.
Activity Destination	Displays the activity destination properties as subnodes.
Event	Displays the event instance properties as subnodes.
Line	Displays the line instance properties as subnodes.

The K2 Toolbox contains K2 blackpearl wizard and components. The following table describes the Toolbox contents in more detail:

The K2 Design Canvas provides a drag-and-drop environment to facilitate workflow design. Activities, events, and Line Rules can be dragged from the K2 Toolbox onto the canvas.

In most cases when a developer has to start developing a process-driven application such as this, they work from a workflow diagram of the process. Figure 9-9 shows the workflow design that we're going to use to create our first process-driven application using K2 blackpearl.

Figure 9.9. Figure 9-9

The following table explains the workflow and its activities in more detail:

The process has a number of roles that each actor falls into as they complete their task. K2 blackpearl provides a way of creating roles and adding users or groups to each role. These roles can be managed from the Management Console and negate the need for Active Directory Groups to be created. Roles contain RoleItems, which are made up of Active Directory Users or Groups, SmartObject queries, or users and groups from a custom user provider. The SQL user provider is supported out of the box, and roles can include or exclude users from multiple user providers.

We're going to add Active Directory Users to our roles. To add the role, navigate to the K2 Workspace (Start

Add the following four roles with RoleItems:

The end result should look like Figure 9-10.

Figure 9.10. Figure 9-10

One approach that can be taken to initially test the workflow in a development environment is to add your Active Directory User account as the only RoleItem on each Role. This means that you are the only actor on all of the process activities, and as you step through the activities, the next task generated will be assigned to you. This provides a great way to test the logic of your application. However, when setting up the quality assurance (QA), staging, and production environments, make sure to add different users to Roles.

Another approach is to add the different users to the Roles as outlined previously in the chapter. When you need to test the workflow, either log in as different users (which can be time-consuming) or right-click on Internet Explorer and select Run as the option. Type in the user credentials you're impersonating, and click OK. This launches the browser in the context of that user.

Data fields are variables within the running workflow. There are two levels of data fields: Process and activity data Fields.

Data fields are added from the K2 Object Browser. To create data fields:

We are going to use this data field to dynamically route a process activity later in the chapter.

Now that Roles have been defined, it's time to add the process activities to the K2 Design Canvas. Activities act as containers for one or more events. Where there are multiple events, the events are processed in the order that they have been added to the activity, and all need to be completed prior to the activity being completed.

There are a few ways of adding activities to the canvas.

When building out the workflow, you can take a couple of approaches:

How you develop your process-driven application will depend on your preference. In order to explain the concepts behind each object (activities, events, Line Rules, and so on) we'll adopt the second approach. Let's get started.

Now that we have added our first activity, we are going to add the rest of the activities as outlined in the following table:

To recap, so far we've added the activities required for the workflow, given each a name and description, and set their Destination Rule. The next step is to add events to each activity.

We're going to start off simple by adding a Forms Generation Client Event to each activity. This event allows us to incorporate client forms for use with each activity. The form is generated as part of the wizard execution process, producing a template or form as a type of framework that can be altered to suit the user requirements.

Customized, audience-specific form templates can also be produced, and these are consumed at design time by the Forms Generation Client Event as part of the design-time process.

It's time to get started.

Now that we have added our first event, we can go ahead and add a Forms Generation Client Event to the rest of the activities as outlined in the following table:

Line Rules are used to connect one activity to another and dictate the flow of the process. Line Rules have the ability to store rule logic. The logic is simply a condition or set of conditions under which the Line Rule evaluates to true. By default, Line Rules return true. These sets of conditions translate into business logic, directing the workflow process to the appropriate destination users.

You need a Line Rule to connect the Start Activity to the first activity in the example process, Create Request. There are a couple of ways you can add this Line Rule.

You might notice that the Create Request activity has a Line Rule attached to the bottom of it. This was created by the Forms Generation Client Event Wizard. You need to connect these Line Rules to their respective activities. Hover the mouse over the Line Rule where the arrow is and click and drag it to the Assign Subject Matter Expert activity. This ensures that the Create Request activity will flow to the Assign Subject Matter Expert activity once it has been completed.

It's time to take a quick look at the logic behind this Line Rule. You can view the logic by right-clicking on the Line Rule on the canvas and selecting Properties. The first tab shows the Line General Properties. Click on the second icon in the icon menu on the left (as shown in Figure 9-24).

Figure 9.24. Figure 9-24

You will notice that a Line Rule has been added for us. This was done using the Forms Generation Client Event Wizard. You have the ability to add more rules to the line from here if needed.

However, it's time to get on with connecting the activities. Connect the activities to each other using the lines as follows:

Now that the activities are connected, the design canvas should look like Figure 9-25.

Figure 9.25. Figure 9-25

You are now ready to build and deploy your K2 Workflow project. You should note, however, that while our goal in this chapter is to create our first workflow, the deployment steps outlined in this section deal specifically with the default deployment on your development environment. Chapters 5, 6, and 10 go into further detail regarding deployment strategies and deploying to multiple environments.

Let's get deployed:

The workflow has now been successfully deployed to the Workflow server. Next you need to set the Process Rights.

Setting the Process Rights ensures that the process can be accessed by the workflow actors. The following table explains the permissions available:

To set the Process Rights you either add the user's Active Directory User account or an Active Directory Group that the user may belong to. The following steps set the Process Rights for users in the example:

Your Management Console should look like Figure 9-28.

Figure 9.28. Figure 9-28

To initiate the workflow, you're going to log on as Request Coordinator, Codi. Alternatively, you can right-click on Internet Explorer and run as Codi.

When Mike navigates to his K2 Workspace, he will see that he has a new Create Request task. Mike's K2 Workspace should look like Figure 9-30.

Figure 9.30. Figure 9-30

There are two ways for Mike to complete his task.

To complete this task, you can use the page generated by the Forms Generation Client Event. Click on the Event Name, and the client-generated page opens in a new browser window. There are a couple of important things to note here:

Mike's form should look like Figure 9-32.

Figure 9.32. Figure 9-32

Select the Create Request action, and click the Submit button. As soon as the task has been completed, the client page displays a message confirming that the Worklist item action has been completed.

The workflow creates a new Assign Subject Matter Expert task for Anthony. You can complete the task as Anthony by opening a browser under his credentials. Navigate to his task on the K2 Worklist, and click on the Event Name to launch the client form. The form associated with this task has a textbox where you can assign a Subject Matter Expert to complete the response. Anthony enters DOMAIN Codi (enter your domain before the user's name) and selects the Assign SME action from the Actions drop-down list. His form should look like Figure 9-33.

Figure 9.33. Figure 9-33

The process now creates a new task, Complete Response, for Codi. Remember, the reason this task is going to Codi is because you set the Destination User for this activity to be the value from the SubjectMatterExpert data field. This is an important concept, as you can imagine how powerful this can be. You can have a drop-down list containing several users who are part of a group, and the actor completing this task can select a person at run time.

Log in as Codi and complete her task. Once this task has been submitted, a new Approve Response task is created and assigned to Mike. Take a look as the action available to Mike from his K2 Workspace. Notice now there are two actions available, Approve and Decline, as displayed in Figure 9-34.

Figure 9.34. Figure 9-34

Depending on Mike's actions one of two outcomes can occur. If he Declines the response, then the workflow is routed back to Codi so that she can have another attempt at completing the response. On the other hand, if Mike approves the response, the workflow is routed to the next activity, Post Response.

Approve the response. A new Post Response task is created for Mike. As soon as Mike has completed the task, the workflow instance has been completed. There you go, one process-driven application later, and you've hardly broken into a sweat.