The K2 blackpearl platform allows for collaborative process modeling by changing the paradigm in which processes are designed. Collaborative modeling allows for a "Big Picture" view of a business's processes, allowing end users, business analysts, and developers to work together to address a broad range of business challenges.
This chapter will discuss the various K2 design surfaces, as well as how the designers work together effectively based on the skill set and role of the project team member. This chapter also covers the following topics:
The roles involved when a K2 process is designed
The designer choices available with K2 blackpearl, including the K2 Designer for Visio, the K2 Web Designer for SharePoint, and the K2 Designer for Visual Studio
Collaborating on a process using the various K2 design tools
People are involved in application and process design; that's common sense. What's interesting is the type of people that can be involved. The K2 platform works process designs declaratively, meaning that the definition of the process is independent of the designer that was used to create it. This allows different design experiences for different types of people with varying technical skills.
Some organizations have fairly rigid standards for building and deploying business solutions. It does not matter whether you mandate that IT must be responsible for all software builds and changes or if you allow other people in the business to actively participate. K2 blackpearl was designed to handle these scenarios and anything in between, as shown in Figure 14-1.
Because a process designer can have a variety of skillsets, the K2 process designers cater to the various technical and nontechnical user bases. For example, Microsoft Office Visio 2007 can be used to map a process by the business process owner. After the owner has described the process visually, a business analyst can add additional process definition information also using Visio. Once the process has been defined to the limit of their technical capabilities, the process definition can be passed on to a developer to finish the process using Visual Studio.
All K2 design canvases are visual, leveraging drag-and-drop and wizard-driven interfaces to guide designers without requiring significant technical ability. Microsoft .NET Framework 3.0 Windows Workflow Foundation Schedules and associated Microsoft .NET code are automatically created, regardless of designer, for interoperability and extensibility.
K2 provides three types of process designers today, and additional design canvases are planned. Each canvas is targeted at a specific type of person, as shown in Figure 14-2.
From left to right, the process designers move from technical complexity to easy use:
The K2 Designer for Visual Studio is for IT professionals comfortable working within the Microsoft Visual Studio 2005 environment.
The K2 Designer for Visio can be used by anyone comfortable with Microsoft Visio, but is generally used by a business analyst.
The K2 Web Designer for SharePoint is for the SharePoint 2007 user or power user who wants to design and run workflows within the SharePoint environment.
Each designer will be discussed in more detail in later sections, as well as the planned designers to be released with later versions of K2 blackpearl. Before we get into detail about the design surfaces, it is important to start with some definitions.
As defined in Chapter 3, there are several roles that play a part in a K2 automation project. When it comes down to the task of designing the process, there are three key roles or audiences that we will discuss:
Business analyst
Process designer
Developer
While the other roles in a K2 project are important, these three roles are the ones who will actually sit down and design the process using the K2 design tools.
While one of the main jobs of the business analyst is documentation of the process, including the business requirements, use cases, form design, and data requirements, K2 allows the business analyst to also play a key role in designing the process. Using tools such as the K2 Designer for Visio, the business analyst can map the process using common business stencils based on the requirements gathered during the design phase of the project.
The process designer is generally responsible for the design of the application. Many times, a process designer can also be the business analyst and can use tools like the K2 Designer for Visio to develop the business processes. More than just defining the process using shapes, the process designer also connects the shapes with the appropriate K2 wizards to begin to develop the K2 process. For simple processes without requiring custom code, the process designer can completely build the process and deploy. For more complicated processes, the process designer can export the process and send to a developer to enhance.
The developer is responsible for developing any custom code that is needed as well as the integration points into line-of-business systems. The developer will use tools such as the K2 Designer for Visual Studio to build on the process designed by the process designer in tools such as the K2 Designer for Visio to incorporate custom code. The developer is also responsible for the creation of SmartObjects, as that functionality is not included within the K2 Designer for Visio.
When working on a business process automation project, many people will be working on the same project. Depending on the scenario, like the example mentioned previously, a business process owner, business analyst, and a developer could all be involved in defining the K2 process. The K2 process definition framework makes sure that the core definition is the same, regardless of the design canvas used to model the process. The framework abstracts the process definition, or the logic and routing information necessary for K2 to run the process, from the view information, or the layout and visual representation of the activities, events, and lines. The process definition framework allows each participant in the process-modeling experience to use the process design tool that best fits their skill sets. At the same time, by having a common definition, participants can collaborate using a variety of tools.
Every K2 design surface uses the same project file system. All design tools employ the same K2 API to maintain the project (.kprx) file and create the supporting build files, whether or not Visual Studio is installed on the machine. The presentation of the workflow integration in each design canvas may be different, but the core pieces that make up the workflow are the same regardless of the design environment. In this way the design of the workflow is completely separated from the visualization of the workflow, which is precisely why collaborative design can occur on the K2 platform.
The building and deployment of workflows is the same across designers as well. The MSBuild scripts and mechanism by which processes are deployed to a K2 server is exactly the same for every design environment because the same API is used for all designers. Moreover, the K2 Designer for Visual Studio and K2 Designer for Visio (and the K2 Studio designer, not yet released at the time of writing) use the same wizards, so the configuration of processes, activities, and events are the same across designers. This also allows any custom wizards to be used across designers so that business users using K2 Studio or the K2 Designer for Visio can use the same interface as developers using Visual Studio.
Each K2 design surface creates the same project, folder, and file structure. It is the K2 API that defines this structure, which allows the flexibility for multiple designers to work with the same K2 project.
Also, because the visual design of the process and authoring of the process files are separated, there can be a disconnect between the visual model and the process definition. For example, in the K2 Designer for Visio, you may see orphaned activities and events. These orphaned items may have been added in Visual Studio but are not associated to a shape in Visio. Even though they are not visually represented on the canvas, they will be executed as they are represented in the process definition.
Think of this like a blue print to a building. If you were to pull a blue print of your house, you will see the layout of the rooms, entrances, windows, and so on. However, you may not see the details of the electrical or HVAC systems. Even though they are not visually represented in the house blue print, they are defined in another layer and are used within the execution of building the house (and during the day-to-day maintenance of the house, for example when the air conditioning kicks-in).
Using a process designer like the K2 Designer for Visio, you can represent the large activities or human interactions with shapes, much like the rooms in your house. Then, using a designer like the K2 Designer for Visual Studio, you can add in the details for the process, much like the electrical or HVAC systems. When viewing the completely defined process, the technical details may not be represented visually on the Visio page; they are represented within the process definition and will be executed during the run time of the process. Many times the project sponsors or business analysts are not interested in the technical details but only want to see the higher-level overview of the process. Therefore, the visual representation of the process in a Visio diagram is easier for the nontechnical users to understand.
Define a Process Completely via Code
Because the visual representation and the process definition are independent, you can create a process completely via code without using a visual designer. You can define the .kprx using the K2 API, which can then be opened in Visual Studio or imported into Visio. See the K2 blackpearl Developer Reference for more information. Look for the Processes
As part of the K2 API, process definitions can be exported from the various design surfaces. This creates the necessary project, folder, and file structure so that the process design can be used by the other process designers.
However, there are some limitations on which designers can share processes with other designers. The following list shows the process sharing capabilities of the various K2 blackpearl designers.
Save from the K2 Designer for Visual Studio :
K2 Designer for Visio: Can open and map unbound activities to new shapes.
K2 Web Designer for SharePoint: Cannot open.
Save from K2 Designer for Visio :
K2 Designer for Visual Studio: Can open and continue designing with no additional tasks.
K2 Web Designer for SharePoint: Cannot open.
Save from K2 Web Designer for SharePoint :
K2 Designer for Visual Studio: Can open and continue designing; process should be deployed as a new process.
K2 Designer for Visio: Can open and map unbound activities to new shapes; process should be deployed as a new process.
The reason that the K2 Web Designer cannot open processes designed in the K2 Designer for Visual Studio or the K2 Designer for Visio is based on the limited selection of wizards available within the Web Designer, which will be discussed in detail in a later section. It is strongly recommended that, if a K2 Web Designer process is modified by another design tool, the name be changed before deploying the process again. Because the end user who created the process in the Web Designer can still make changes to the "old" process and deploy it, this can cause issues with the versioning of the process and general headaches. By changing the name of the process before deploying from another designer, you can alleviate this issue and keep the Web Designer process from overwriting the changes.
K2 provides a unique process-modeling experience that supports multiple, interchangeable canvases and tools. K2 abstracts the view information from the process definition to ensure that the core process definition is the same, regardless of the canvas or tool. The result is a solution platform that allows each participant in the process modeling experience, regardless of role (for example, business analyst, developer, process owner), to use the modeling environment in which they are most comfortable. We will next talk about the design tools that exist with K2 blackpearl at the time of writing.
The K2 Designer for Visio is an add-in for Microsoft Office Visio 2007, bringing the tools available in the K2 Designer for Visual Studio to the Visio environment. By using layers instead of stencils, activities, events, and rules can be associated with any shape on the Visio canvas. This association is not limited to one activity or event per shape. For example, multiple activities can be attached to a single shape if the business requirements and existing drawing require it. This can be useful for drawings that do not model a process but need to be used to build and deploy one, such as a floor plan or an architectural drawing of a network.
Microsoft Visio helps people create professional-looking diagrams of all types. Most software programs of its kind rely on the users' artistic skills to make advanced drawings. But with Microsoft Office Visio 2007, it is as easy as opening a template and dragging the icons and stencils onto the canvas. Many companies already own Visio, and often it is already deployed to the process owners' desktops.
All K2 blackpearl components present in the Visual Studio Toolbox can be inserted on a new or existing Visio drawing. The same wizards available in Visual Studio are used to design specific pieces of a process in Visio, such as adding a SharePoint document event to move or copy a document stored on a SharePoint site.
The K2 Object Browser, which displays the Environment library, process and activity data, and the Workflow Data and User and Roles browsers, is available in Visio as well as Visual Studio. Most processes that can be built in Visual Studio can be built with the K2 Designer for Visio; however, custom code and debugging of processes are not available in Visio.
By using the K2 Designer for Visio, processes can be built and deployed from within the Visio environment. The Visio Designer leverages a familiar tool set and exposes the K2 tools for easy integration of drawings with process modeling. Now the K2 Designer for Visio can take these diagrams and bring them to life. Figure 14-3 below shows an example Visio diagram that has been wired to a K2 workflow.
The K2 information is stored as another layer on top of the Visio diagram. In this way, the original diagram is preserved. You can turn off and on the visibility of the K2 layer so that the additional information (the green lines and K2 icons) does not confuse the viewer with the original K2 layer. For simple diagrams as shown in Figure 14-3, this does not pose an issue. However, with complicated diagrams the additional K2 layer can cause confusion.
The K2 Designer for Visio also takes advantage of easy-to-use wizards. These wizards are the same across many of the design surfaces, including Visio and Visual Studio. By having common wizards, the power of the K2 platform can be leveraged across multiple design surfaces, while allowing the end user to design in a simple Visio-based experience.
The person designing the process can choose between two means of process-enabling Visio diagrams: by activity or by process. A designer can automate processes in an ad hoc fashion, choosing shapes and then binding those shapes to events. For example, a designer might open an existing Visio 2007 diagram and then manually enable activities by selecting the shape, right clicking, and configuring an event (such as sending an e-mail or publishing a document) through a wizard. Alternatively, a designer can create a new process and enable the entire surface, thereby prompting the user to tie the shape to an event or rule when the shape is first dropped onto the design surface.
There are no specific one-shape-to-one-step limitations. This is too restrictive for some advanced processes or those that may follow alternative diagramming methods (for example, a floor plan). Multiple shapes may be used to define various steps, the participants and the decisions to be made. These can be grouped together in Visio and treated as a single K2 activity. Then the process author can begin assigning workflow steps to each stencil item or group of stencil items.
The K2 Designer for Visio is intended for a business analyst to use to model processes. However, the design experience is robust enough that developers may choose to model processes using Visio.
In order to be successful with the K2 Designer for Visio, the user should be familiar with Visio concepts, such as using shapes, labels, and lines, as well as K2 concepts such as actions, outcomes, activities, events, and rules.
When the K2 Designer for Visio has been installed on a client machine that has Microsoft Office Visio 2007 already installed, a new K2 toolbar becomes available within Visio. This toolbar is shown in Figure 14-4.
From left to right, the buttons include:
Enable/Disable K2 Workflow: Allow or remove K2 Integration to the Visio drawing.
Add K2 Workflow Item to Shape: Bind a K2 workflow item to a shape.
Remove K2 Workflow Item from Shape: Remove the binding to a K2 workflow item on a shape.
Add K2 Workflow Item to Shape on Drop: Opens the Bind to the Workflow Wizard when dropping a shape on the Visio page.
Toggle K2 Workflow Layers: Display or hide the K2 layer on the Visio diagram.
Toggle Workflow Anchor Window Visibility: Display or hide the K2 Designer for Visio task pane, including the Workflow and K2 Object Browser.
Import: Import an existing K2 workflow to the Visio diagram.
Export: Export the Visio designed workflow.
Deploy: Deploy the Visio designed workflow to the K2 server.
Build Manager: Change the pages and workflow that are used to build and deploy.
Settings: Change K2 Designer for Visio settings.
To create a K2 integrated process in Microsoft Office Visio 2007, you must first enable the diagram to support K2 integration. This can be accomplished by clicking on the Enable K2 Workflow button. By enabling K2 integration, any of the shapes in the process can be bound to a K2 blackpearl workflow process. Binding shapes is easy and only requires a few clicks of the mouse.
When you right-click on a shape and select the K2 Integration menu item, the available menu items will be displayed based on the workflow configuration. For example, Figure 14-5 shows a diagram that has been integrated with a K2 workflow. By right-clicking on the start shape, you can change the lines or properties of that shape. The shapes that have been connected to a K2 activity will display a K2 icon next to the shape, as shown below. The icon is displayed on the K2 layer, and if this workflow layer is turned off the icons and lines will be hidden.
From a Visio diagram you can build a K2 process from scratch by integrating shapes with new workflow activities. You can bind any shape to any of the available K2 event wizards. The K2 Designer for Visio will walk you through a series of wizards to associate a shape with first the activity, then the Event Wizard. Depending on the event selected, additional sub wizards will be displayed to guide you through the process of configuring the event. These wizards are exactly the same as the wizards that are displayed in Visual Studio.
For more details on the K2 wizards, please see Chapter 8.
Once all of the shapes have been associated with workflow events, you need to connect them. Activities are joined by using the K2 Integration menu and configuring the lines. This is different than connecting lines in Visual Studio, as you cannot drag-and-drop the line stubs from actions to connect activities.
Rather than building a process from scratch in Visio, a business analyst can also import an existing process that a developer has created in Visual Studio and map the process activities to shapes. Once a process has been imported into Visio, the user can map unbound activities to shapes.
Processes can be imported into Visio by choosing the Import button on the K2 toolbar.
To export a process out of Visio, click on the Export button on the K2 toolbar. Once exported all the files in the specified export location can be handed off to a developer for extending the process. The folder that the process was exported to will contain a complete K2 blackpearl project (.k2proj file) and process (.kprx file) that can be handed off to a developer for further customization. The project can be opened directly in Visual Studio, modified by the developer, and saved.
Once the developer has finished the modifications, the business analyst will open the Visio diagram and import the new process definition. Any of the already bound activities and lines will display on the K2 layer. Any activities that were added to the process definition in Visual Studio will be displayed as unbound activities. These new activities can be integrated with a shape in Visio for the visual representation. However, the process will still execute correctly even if it is not bound to a Visio shape. Remember, the visual representation layer and the process definition are separate. As long as the process definition is complete, the process will run correctly.
Processes designed in Visio can be opened within the K2 Designer for Visual Studio, modified, extended, and imported again to Visio for further changes or adjustments. This gives Visio and Visual Studio users the ability to collaborate on process design in comfortable and skill-appropriate environments.
The collaboration experience is bidirectional, meaning the process definition can begin in Visio or in Visual Studio and can be shared back and forth. For example, the business analyst can start from a blank Visio page, design the process using shapes and lines, and then wire up the page to new K2 activities and events. Or, the developer can build a K2 process, which the business analyst can then import into a new or existing Visio diagram and then attach the activities to the appropriate shapes.
For forms development, custom ASP.NET pages cannot be created in Visio. They must be created using a development tool such as Visual Studio. However, the developer can create the necessary pages and give the URL information to the process designer for use within client event wizards in Visio. If an InfoPath form has already been created, the process designer can integrate the Visio diagram with an InfoPath process wizard to fully implement the process using InfoPath forms. Design of the InfoPath form must be done in Microsoft Office InfoPath 2007.
The K2 Designer for Visio design experience is not limited by what is available out-of-the-box. The platform is intended for collaboration and extension. For example, developers can create custom ASP.NET forms and preconfigured wizards with steps and actions for use by Visio process designers.
Process designers can also work with developers to extend capabilities that can't be solely enabled through available wizards. Processes can be shared by exporting the process from Visio and then opening the process with the K2 Designer for Visual Studio. All of the configured activities, events, and properties from Visio will be accessible from Visual Studio. The developer can use a full set of K2 tools, Visual Studio tools, and custom code to complete the process logic. The developer can check in the file for validation by the process designer. The process designer can reopen the process within Visio. If the developer creates objects that Visio is unable to interpret, the K2 Designer for Visio will allow the user to create associations between a Visio shape and the orphaned object.
The K2 Designer for Visio is intended for a business analyst to be able to quickly wire up diagrams with key K2 activities and events. The Visio Designer should be used when:
The business analyst needs to take written requirements and turn them into a visual representation of the process flow. By starting with Visio, the visual information about the process can be reused in Visual Studio, making it a jump start for the developer.
The business analyst knows enough about K2 to be able to wire up the diagram with the process definition. You can either start with the diagram or start with a prebuilt process from Visual Studio. At the end, you will have a fully defined K2 process ready to be deployed and tested.
Visio is not the appropriate design surface for all users. The Visio designer should not be used when:
The developer is not familiar or comfortable with Visio. You should use the design surface that you are most comfortable with in order to rapidly develop your K2 processes.
There is custom code that needs to be created behind the wizards. The Visio designer does not expose the code editing capabilities of the K2 platform. The Visual Studio designer is more appropriate when custom code needs to be created. However, if code modules have already been written and exposed as K2 wizards, they can be used within the Visio designer.
SmartObjects need to be created for the first time. The K2 Designer for Visio does not include a design canvas for SmartObjects; these must be created in Visual Studio. However, once a SmartObject has been designed and deployed, it can be used within the Visio Designer from the K2 Object Browser.
The information that follows is based on the K2 Web Designer for SharePoint version (1.0) that is currently available with K2 blackpearl 0803 at the time of writing. The Web Designer is undergoing some major changes, which will be discussed in a later section.
Business users can visually model, build, and deploy processes using the K2 Web Designer for SharePoint, surfaced within SharePoint 2007. The K2 Web Designer for SharePoint is accessible to design workflows for any library or list within a SharePoint site collection. One of the great advantages to using the K2 Web Designer for SharePoint is that the SharePoint context is built in. This means that you can use SharePoint metadata from the list item or document in Line Rules, or use people columns as Destination Rules. Because this context is understood by the K2 Web Designer, as soon as you start designing a K2 process this information is available to you.
In order to accelerate the design process using the K2 Web Designer for SharePoint, Outcome templates are prebuilt to describe the actions that a user can take at a given point in the process. Wizards are also available to define what happens to the SharePoint item (either the document or list item that started the K2 process) as a result of the user's selected action. K2 provides a visual drag-and-drop and wizard-driven interface for building SharePoint-based processes from within the Web browser. SharePoint users can build processes that span documents, sites, libraries, lists, and more, without the need to build forms or understand technical concepts.
The designer is available for Microsoft Office SharePoint Server (MOSS) 2007 and Windows SharePoint Services (WSS) 3.0. Once the feature has been activated on a site collection, the K2 Web Designer for SharePoint is available from any document library or list. The design surface displays within the browser within the same frame as the SharePoint site, as shown in Figure 14-6.
Because the K2 Web Designer for SharePoint is intended for power users and business analysts, the Sidebar contains a series of Outcome templates and wizards that can be used within the context of the K2 process. This will be described further in a later section.
Because the wizard list is restricted in the K2 Web Designer for SharePoint, this design surface is not as robust as the Visio Designer or the Visual Studio Designer. However, it is easier for an end user to design simple processes that center around a document or list item within SharePoint.
The K2 Web Designer for SharePoint is intended for a power user or a business analyst to create simple, SharePoint-based processes. This designer offers a graphical workflow design experience within a Web browser for business users who do not desire or have the skills to write custom code.
The major advantage to hosting the Workflow Designer within the browser is a broad reach to users in an organization. This allows users who do not want or need Visual Studio 2005 or Visio 2007 to participate in K2 workflow design. However, the browser experience is not the same as a traditional Windows-based development environment.
In order to be successful with the K2 Web Designer for SharePoint, the user should be familiar with SharePoint concepts, such as documents, lists, libraries, records management, and permissions, as well as K2 concepts such as actions, outcomes, activities, and events.
Additionally, a SharePoint administrator is required to deploy this service to a SharePoint server farm. While the administrator may not need to know the details around the Web Designer, he or she should be familiar with deploying features within SharePoint. More information about deploying the K2 Web Designer can be found in Chapter 12.
The K2 Web Designer for SharePoint is available from the Settings menu on any List or Library in a site collection where the feature has been activated. For more information on how to activate the Web Designer feature, see Chapter 12. Figure 14-7 shows the Settings menu with the K2 Web Designer option. This option is only displayed if you have the appropriate permissions.
After the Web Designer is opened, you will see a list of your personal processes as well as those that have been shared by others. You can select one of the listed processes to Edit, Share, or Export, or you can create a New Process. These options are shown in the toolbar of the K2 Web Designer, as shown in Figure 14-8. If you have opened the K2 Web Designer from a list, only processes that have been designed for lists will be displayed. Similarly, if you are looking at the K2 Web Designer from a document library, the processes that have been designed for document libraries will be listed.
Sharing a process will allow other users who have permission to use the K2 Web Designer to see the process in the Shared Processes section of the home page. Shared processes can be modified and redeployed by any member of the site with sufficient permissions.
Exporting a process will build the process definition and ensure that only complete processes are exported. Exporting a process creates a self-extracting .zip file (*.exe) that you can save local and then extract. This will create the necessary project and process files that can then be opened directly in Visual Studio, or can be imported into a Visio diagram.
Clicking New Process produces a prompt that asks you for the name of your process and offers different start options, such as start manually, when an item is created or when an item is changed. For a Form Library process, you must have an InfoPath form published to the library before you can create a new process. The start option for an InfoPath process is Start View. After you enter the information, the K2 Web Designer canvas is displayed.
The Sidebar contains all of the features that you can use when designing processes in the K2 Web Designer, as shown in Figure 14-9.
These Sidebar items will be discussed in detail and include:
Action Menu: Buttons that allow you to Save, Deploy, Save as a Template, or change the Properties of the process.
Templates: Outcome templates define the flow of activities for the process.
Favorites: Ability to store users and groups as favorites gives you a quick reference to frequently used items, to speed up the design experience.
Wizards: Based on where the process is being designed (a list, document library, or forms library) the list of available wizards will change and be displayed in this menu.
Process Templates: Ability to use processes that have been saved as templates for quick design reuse.
Users and Groups: Similar to the User Browser in Visio or Visual Studio, this item will display the SharePoint Users or Groups that can be used within the process.
Across the top of the Sidebar are the Action Menu buttons. While designing your process, you can save it (strongly recommended to save frequently when designing large processes); deploy it to the K2 server, which allows it to run based on your start options; use the Save as Template option, which allows others to use this process as a starting point when designing new processes; or edit the properties of the process (such as the name, description, and start options).
Deploying the process will launch a wizard to check the process definition for missing information, and upon a successful validation, deploy the process to the K2 server. Any errors found when checking the process will be listed so that you can fix the issue and try the deployment again. The deployment process is similar to deploying projects from other K2 Designers, although it is more automated because the environment context is known. You cannot deploy a K2 Web Designer process to a different SharePoint environment. In other words, you cannot design the process on the test SharePoint URL and deploy it to production. To move between environments, you will have to export the process and deploy it using a different K2 Designer.
Outcome templates describe the actions that can be taken by the user and are not able to be modified. The prebuilt templates include the following:
Approve-Decline
Approve-Decline-More Info
Approve-Decline-Review
Approve-Decline-Rework
Approve-Retry
Back
Close Outcome
No Outcome
Retry-Close
By using the Outcome templates, the flow of the K2 process is defined. This basically defines the activities for the K2 process. By dropping a template onto the design canvas, a wizard opens which asks for the activity name and description, as well as the actions and outcomes available as part of this activity. Depending on the template that you used, these are already defined for you. However, you can add, edit, or remove actions and outcomes to customize your process. For more information on actions and outcomes, please see Chapter 8.
Once the activities have been identified, then the events need to be described. Because the K2 Web Designer can only design SharePoint based processes, not all of the K2 Wizards are available within the designer. Based on where the process is being designed (a List, Document Library or Form Library), the available wizards will change. Each wizard uses the context of the item that started the workflow. In other words, if the workflow is set to start when a new item is added, the newly added item becomes the workflow context. The wizards act upon this item.
The wizards are limited according to the following table:
Document Wizards | Description | Available In |
|---|---|---|
Check In Document | Checks in the document using the version control feature of SharePoint. | Document Library |
Check Out Document | Checks out the document using the version control feature of SharePoint. | Document Library |
Copy Document | Copies the document to the destination document library, but leaves the document in the source document library. | Document Library |
Delete Document | Deletes the document. | Document Library |
Move Document | Moves the document from the source document library to the destination document library. | Document Library |
Mail Wizards | Description | Available In |
Send Mail | Sends an e-mail notification, and can include metadata from the form, document, or list item. | Document Library List Form Library |
List Item Wizards | Description | Available In |
Create List Item | Creates a new list item on a destination list. | Document Library |
Copy List Item | Copies the list item from the source list to a destination list. | Document Library List |
Delete List Item | Deletes the list item from the source list. | Document Library List |
Record Management Wizards | Description | Available in |
Send Document to Record Center | Copies the document to the Record Center using the Records Management feature of MOSS. | Document Library |
Place Hold on Record | Places a hold on a document already in the Record Center using the Records Management feature of MOSS. | Document Library |
Remove Hold from Record | Removes a hold from a document already in the Record Center using the Records Management feature of MOSS. | Document Library |
Delete Record | Deletes a document from the Record Center using the Records Management feature of MOSS. | Document Library |
Forms libraries must have an InfoPath form published to the library before a workflow can be designed. Only the mail wizard is available when designing a workflow with an InfoPath form. For more complicated processes, do not use the K2 Web Designer.
For more details on what the SharePoint wizards are used for, please see Chapter 13.
When you are setting the destinations for the various activities, you have the ability to store the users as favorites, as shown in Figure 14-10. Once a user or a group has been added as a favorite, it will display under the Favorites section of the Sidebar. For users or SharePoint groups that you use frequently in processes, it is a good idea to save them as a favorite to quickly drag-and-drop them onto activities to speed up setting the destinations.
Once you have designed and configured a process, you can save it as a process template. This allows you to save processes or sections of processes as templates in order to speed up the design process. For example, you can configure a two step approval process where the decline steps send e-mails to the originator and save it as a process template. The next time you are building a process where you have this type of two-step approval process, rather than starting from scratch and configuring the approval steps again, you can drag on the process template and save some time.
A process template creates a copy of the template definition in the process you are designing. It is not a reference back to the original process, so if you change a process it is not reflected in other processes that use it as a template. Process templates cannot be edited, and can only be dropped onto the default "Form Submitted" activity. This means they can be used at the beginning of a process but cannot be stacked as building blocks.
The available Users and Groups in the site collection in which you are designing a process will be displayed in the Sidebar. You can drag and drop the SharePoint groups onto an activity to quickly set that group as the destination. Remember that the Sidebar only shows the particular users and groups that have been granted explicit rights to the list or library from which you accessed the K2 Web Designer. If you do not see the group listed that you want to use, try opening the destination properties of the activity. This will let you search for users or groups within the context of your site collection. If you still do not see the group listed, they may not have access to the site collection. Check the SharePoint permissions and try again.
Processes created in the K2 Web Designer for SharePoint can be exported. This creates the necessary project, folder, and file structure using the K2 API so that the process can be used in the other design surfaces. Once exported, the process can be imported into the K2 Designer for Visio and attached to a diagram. The process can also be opened directly in the K2 Designer for Visual Studio for more sophisticated activities and integration.
Once the process has been modified by Visio or Visual Studio, it can no longer be modified using the K2 Web Designer for SharePoint. This is due to the wizard limitations in the K2 Web Designer. It is also strongly recommended that if a K2 Web Designer process is modified by another design tool that the name is changed before deploying the process again. Because the end user who created the process in the Web Designer can still make changes to the "old" process and deploy, this can cause issues with the versioning of the process and general headaches. By changing the name of the process before deploying from another designer, you can alleviate this issue and keep the Web Designer process from overwriting the changes.
The key to this collaboration experience is communication. Be sure to tell the person who designed the process using the Web Designer that it has been modified and that they should no longer use the Web Designer to make changes, but instead go through the necessary procedures to make changes using the other designers.
While the same wizards that are used in the other design tools are not used within the K2 Web Designer, there are some extensibility points. However, these are not code-based.
The K2 Web Designer has the concept of templates, whereby a user can save a process as a template. This allows for the process to be designed once and reused. For example, a process is defined and configured to start the same way, perhaps on upload of a document, and based on a form value, a different process can be followed. By saving the starting configuration of a process as a template, the business user can worry about the process after the document has been uploaded rather than the beginning point of the workflow.
The end user can also save items into their Favorites within the K2 Web Designer, making it faster to access commonly used items, such as destinations (users or SharePoint groups). This allows for a customized experience per user.
While the process designed is aware of the SharePoint list or library it has been launched from, a deployed Web Designer process is in actuality a SharePoint feature. Once deployed, the feature is automatically associated with the list or library for which it was designed. However, a deployed workflow is available for use in other lists or libraries throughout the entire SharePoint site collection by associating the feature to the appropriate list. This is another way to design once and reuse the process.
The K2 Web Designer for SharePoint is a simple design tool that should be used when:
The end user wants to create simple SharePoint-based workflows, where the available wizards are all that are necessary for the process. Remember that the document and list item wizards are reduced in the K2 Web Designer; for use of all the available wizards use a different K2 Designer.
When a process is SharePoint-centric, meaning all items within the process are surrounding a document, list item, or form within SharePoint.
The K2 Web Designer for SharePoint should not be used when:
More complex workflows are required, where the prebuilt Outcome templates are not flexible enough. For example, more complicated workflow design solutions, such as the Spider workflow, cannot be created using the K2 Web Designer. Also, altering the task and workflow history lists for SharePoint workflow integration processes is not possible using the K2 Web Designer.
There is custom code that needs to be created. No custom code or custom wizards can be created for the K2 Web Designer. The Visual Studio designer is more appropriate when custom code needs to be created.
SmartObjects need to be created for the first time. The K2 Web Designer does not include a design canvas for SmartObjects; these must be created in Visual Studio. And, SmartObjects cannot be used within the K2 Web Designer, so any process that will rely on line-of-business data should be designed using another K2 design tool.
Active Directory groups or users who have not been imported into SharePoint groups or users need to be used. Only SharePoint groups and users are available in the User Browser within the K2 Web Designer for SharePoint.
SharePoint administration tasks need to be part of the workflow. The SharePoint Sites and Workspaces and the SharePoint Lists and Libraries wizards are not accessible via the K2 Web Designer. If your process needs to create sites or libraries using these wizards, use another design tool.
The K2 Designer for Visual Studio is a fully integrated extension of Visual Studio 2005 and provides a powerful design experience, allowing access to all of the K2 tooling and the generated Microsoft .NET Framework 3.0 Windows Workflow Foundation Schedules and associated Microsoft .NET code for all appropriate K2 objects.
At the time of writing, Visual Studio 2008 support is planned and is under development, but only Visual Studio 2005 is supported by K2 blackpearl 0803.
In the K2 Designer for Visual Studio environment, as shown in Figure 14-11, developers simply drag-and-drop components onto the process-design canvas. Windows Presentation Foundation–based wizards — including wizards for integrating with technologies like SharePoint, sending e-mail and displaying ASP.NET or Microsoft Office InfoPath 2007 forms — guide the developer through configuring the underlying Workflow Foundation schedules, rules, and activities. Developers may use the K2-provided Developer Reference to develop their own custom wizards. Processes built in K2 are extensible. K2 leverages .NET 3.0 — including Workflow Foundation (WF), Windows Communication Foundation (WCF), and Windows Presentation Foundation (WPF) — so developers can open and extend processes within the WF design canvas or directly through custom C# code.
As with all of the K2 design tools, wizard-driven templates are made available to the developer, and the developer has the option to access the generated Microsoft .NET components as necessary.
The Solution Explorer exposes the K2 project and associated dependencies. It includes a context menu to build, deploy, and add new items to K2 projects. Behind the scenes, MSBuild is used for building, packaging, and deploying K2 solutions. All project assembly references are automatically added when a new K2 project or process definition is created. K2 projects can also be included in a single solution file with standard .NET artifacts like ASP.NET pages and Windows Forms. InfoPath solutions are integrated into the project system, ensuring the InfoPath form templates files and their associated K2 projects remain in sync for versioning and deployment. Further, developers will have one-click InfoPath design-time access to all InfoPath form templates included within a K2 project.
The K2 Designer for Visual Studio is intended for a developer to use to model processes and business entities. In order to be successful with the K2 Designer for Visual Studio, the developer should be familiar with Visual Studio concepts, such as building, setting properties, deploying, and working with error messages, as well as K2 concepts such as actions, outcomes, activities, events, and rules.
Because the K2 Designer for Visual Studio is the preferred K2 Designer for a developer audience, it has been used throughout this book. In Chapter 7 you learned about creating SmartObjects using Visual Studio. In Chapter 9 you were first introduced to using Visual Studio to design K2 processes. Chapter 11 covered creating custom ASP.NET forms for use as client interactions with processes. For more details on how to use the Visual Studio to design processes, SmartObjects, or custom ASP.NET pages, please refer to these chapters.
Any process designed in the K2 Web Designer for SharePoint or the K2 Designer for Visio may be exported to the K2 Designer for Visual Studio, allowing a developer to enhance those processes. Processes created in the K2 Designer for Visio may also be sent back from Visual Studio, allowing for bidirectional modification of the process by both the business analyst and the developer.
The K2 design experience is not limited by what is available out-of-the-box. The platform is intended for collaboration and extension. For example, developers can create custom ASP.NET pages and preconfigured wizards with steps and actions for use by other process designers. Using the K2 Developer Reference, custom wizards can be developed and then can be used in the K2 Designer for Visio. For more information on creating custom wizards, see the K2 blackpearl Developer Reference.
Process designers can also work with developers to extend capabilities that can't be solely enabled through available wizards. Processes can be exported from Visio and then opened in Visual Studio. A developer is then able to open the process model and any preconfigured activities directly within K2 Designer for Visual Studio. The developer can use a full set of K2 tools, Visual Studio tools, and custom code to complete the process logic. The developer can check in the file for validation by the process designer. The process designer can reopen the process within Visio. If the developer creates objects that Visio is unable to interpret, the K2 Designer for Visio will allow the user to create associations between a Visio shape and the orphaned object.
The K2 Designer for Visual Studio is the most robust of the K2 Designers. It should be used when:
The developer is familiar with and comfortable with developing in Visual Studio. Because the K2 Designer for Visual Studio is completely integrated within the Visual Studio IDE, only the new K2 concepts and toolbars need to be understood before developing a K2 process. This provides for a much smaller learning curve for someone who is already familiar with Visual Studio.
SmartObjects need to be created. At the time of writing, the K2 Designer for Visual Studio is the only design tool where SmartObjects can be created, edited, or deployed.
Custom code needs to be integrated with or consumed within a process definition. The K2 Designer for Visual Studio is the only design tool where the WF schedules or underlying C# code are accessible for modification.
Custom ASP.NET pages or Windows applications need to be created for the client events, or user interactions with the process. While these client interactions can be developed in any technology, Visual Studio makes it easy to reference the K2 APIs, and the K2 blackpearl developer reference has sample projects and code examples for use within Visual Studio.
Because the K2 Designer for Visual Studio is designed for a developer, it should not be used when:
A business analyst wants to model a process. Use one of the other design tools rather than spending the time and money to skill up a business analyst on a developer tool.
For simple, SharePoint-driven processes that can be quickly designed using one of the other designer tools. Visual Studio can be overkill and requires a developer interaction. Other K2 Designers, such as Visio or the Web Designer, can be used effectively when the business analyst or power user has the skills and knowledge required to develop the process.
Because the K2 API creates the framework for the project, folder, and file structure for all K2 processes, the design surface possibilities are endless. The K2 Designer for Visio, the K2 Web Designer for SharePoint, and the K2 Designer for Visual Studio are the three canvases that are available with K2 blackpearl 0803. However, additional design surfaces are in the works and will be available with future releases of K2 blackpearl.
The information provided here on future designers is subject to change, as these design surfaces are still in development. The additional design surfaces will be available in future releases of K2 blackpearl.
With K2 Studio, business users can create process applications within an Office-like application. K2 Studio is a client-side application providing the ability to build a process application using K2's easy-to-use wizards. This benefit allows customers to have a simple design experience, while at the same time leveraging the power the K2 platform has to offer. The K2 Studio designer uses the Microsoft Office look-and-feel, creating a design environment that is familiar and easy to use for business users.
Some of the key features of K2 Studio include:
K2 Toolbox: Providing easy access to K2 blackpearl components and wizards, this toolbox displays the K2 Object Browser and Process and Event wizards for easy access to all the K2 values and wizards when designing a process.
Solution Explorer: All project assembly references are automatically added for you when you start a new K2 project or process definition. This explorer is similar to the Visual Studio Solution Explorer.
Process Helper: To shorten the development cycle, the process helper tool pane shortcuts common wizards into just the minimum requirement information to prototype and build processes faster.
Visual Process Designer: An extendable design canvas for visually modeling workflow and business processes. This design canvas is similar to the Visual Studio design canvas.
SmartObject Designer: This provides a visual interface that allows developers to build and deploy composite data entities.
Process Guides: To assist in the process design, video and step-by-step guides are included to assist first-time process designers in configuring their K2 process.
This standalone application does not require Visual Studio to be installed in order to develop K2 processes and SmartObjects. All the K2 wizards that are available in Visual Studio are also available within K2 Studio. However, you cannot edit code in K2 Studio. You will need Visual Studio in order to modify the WF schedules or code-behind wizards.
Any process designed in K2 Studio may be imported into Visio to wire a Visio diagram, or directly edited in Visual Studio. Because K2 Studio uses the same solution and project file structure as Visual Studio, K2 solutions can be opened in either K2 Studio or Visual Studio for a completely seamless collaboration experience.
K2 Studio is designed for a business analyst to be able to develop K2 processes and SmartObjects easily and effectively. In order to be successful with K2 Studio, the user should be familiar with Office 2007 concepts, such as the ribbon bar and tool panes, as well as K2 concepts such as actions, outcomes, activities, events, and rules.
The K2 Web Designer will be revamped from its current implementation as the K2 Web Designer for SharePoint. The current version focuses on activities and events as the building blocks for processes. The new version will focus on people rather than activities. For example, in the current version you start building your process by thinking about the outcomes (for example, approve-decline), then you think about what happens to the item (for example, move document, delete item). In the next version, you start building your process by thinking of the people that need to interact with that item (for example, manager approval). As in the pawn diagram discussion in Chapter 8, by moving people to the forefront of the discussion around the business process rather than the blocks and lines that make up the process, it is easier to gain buy-in and approval of the newly automated process.
The next version of the K2 Web Designer will also not be dependent on SharePoint in order to design processes. It will still be SharePoint-aware, allowing processes to be built quickly based on the site collection and list or library from which it is launched. However, the K2 Web Designer will also be a standalone Web site to remove the dependency on SharePoint.
As is the first version, the K2 Web Designer is intended for a business analyst or power user to use to develop process-driven applications. While the design canvas and the paradigm for thinking about the business process may change, the user should still be familiar with SharePoint concepts such as documents, lists, libraries, records management, and permissions, as well as K2 concepts such as actions, outcomes, activities, and events.
With the various designers available for the project team to use, it is important to understand some guidelines when working on K2 projects collaboratively. As with any technology project, there are challenges that will exist outside of the boundaries of the project. The next sections will discuss the challenges and best practices to successfully work collaboratively with K2.
Before we discuss the details, let's walk through an example collaborative development scenario. Let's assume that you've already set up the project team, selected your process to automate (in this example, let's use the HR process for bringing new employees on board), and have held meetings to discuss the business requirements and have documented the use cases.
The business analyst takes the requirements and starts to create the process model using Visio. The diagram has been created using the appropriate shapes to accurately depict the process, beginning with the job posting, the interview process, the offer letter, and so on until the employee has been hired and has started their first day on the job. Once the diagram has been approved by the appropriate stakeholders, the business analyst is ready to start developing the process. They starts wiring up the shapes with the appropriate activities and events, starting with a job posting that has been uploaded to a SharePoint document library on the HR site. Because the business analyst understands the K2 concepts and wizards, they are able to successfully wire up a number of the activities in the process. Once an applicant has applied and interviews have been scheduled (stored on an interview calendar on the HR site), and the decision to extend an offer has been made, the offer is actually created by Payroll using their legacy system for employee payroll, raises, and bonuses.
Because the process has now stepped into the realm of system integration and because the business analyst doesn't know the underlying technology for the payroll system, they needs help from the developer. They can save the Visio diagram, and export the K2 process. When they exports the process, the necessary K2 projects and processes are created automatically. The developer can then open the K2 process in Visual Studio and can develop the necessary code to integrate with the payroll system.
Once the developer has completed the integration tasks, which could use a custom code event for example, or a series of SmartObjects to expose data from and update data to the payroll system, he saves the process and tells the business analyst that their work is complete. They can then import the modified process back into the Visio diagram. All the events that were wired up previously will still be connected. The new events that the developer created (which display as orphaned activities in Visio) can be associated with shapes on the Visio diagram and the business analyst can continue working on the process.
The K2 platform allows for tight collaboration among the members of the team by providing a common framework that defines the K2 solutions, projects, and artifacts. However, the technology can only take you so far in working collaboratively. There are considerations outside of the technology that you should look at.
A strong part of any successful project is having a clearly defined scope, project plan, and responsibility matrix. By identifying who is responsible for which tasks and when they are due, you can set expectations early on. Additionally, you can use this opportunity to look at the team members and identify their strengths and weaknesses. Use this to help them learn the new tools they will be using, such as the K2 designers or any project-reporting tools you use. If a team member is not going to be a developer, then don't teach them how to use the K2 Designer for Visual Studio. Instead, focus their energies on the K2 Designer for Visio or another design canvas.
By clearly identifying the responsibilities, from our previous example scenario, the business analyst knows that they is responsible for creating as much of the process as they can. Additionally, they knows who the developer is who is responsible for integration with the payroll system. Having this information defined up front, before any work begins on the process automation, will make it easy for team members to work together effectively.
A business process automation project is just like any other project. If you have a large team of people, make sure that boundaries are set early on with responsibilities and deadlines. Hold people accountable for the tasks that are assigned to them, using whatever method works in your environment, perhaps daily status e-mails or weekly status meetings, or perhaps SharePoint or Microsoft Office Project works in your environment to manage projects. Use the tools to help you keep a handle on the project. While it is mainly the project manager's job to make sure that the project is on task, it is the responsibility of every person on the team to know what they should be working on, and when.
Also make sure that you do not create a massive project plan and then never update it. A good project plan is flexible enough to allow for fire drills that come up during a project. It is also updated frequently with status and progress, so that all the stakeholders and team members know at a glance the project status.
As with any development project, it is a good idea to check in the code for an application to a source code management tool. This way there is a backup of the working code as well as version control and locking so that changes are not overwritten in a large development team.
With K2 blackpearl 0807, checking in K2 solutions and associated files is integrated and fully working within Visual Studio. Any package (such as Microsoft Visual SourceSafe or Team Foundation Server) that can be integrated into Visual Studio as a source code control provider can be used to check in the K2 projects' code. Be sure to configure Visual Studio to integrate with whichever source control package you use to manage your code.
Throughout this book, we've said that K2 is a declarative model, with no compiled code. But now we're talking about managing source code? When you create a K2 process, you are actually building a .kprx file. This is an XML file which declaratively stores all of the configuration properties and customizations that you make to the process definitions. You need to have only this single .kprx file managed under source code control for your process to be protected. If you have other artifacts, such as SmartObjects, custom ASP.NET pages, or InfoPath forms, these will also be checked in to the source code repository when checking in the K2 project.
When working in a development team, there are a few key points to keep in mind:
Only one person can work on a file at a time. Make sure that you set up your integration with source code control to use exclusive check-out. Because the K2 files are based on XML, only one person should be modifying the file at a time. If you have multiple items within a single solution, one developer can be working on the SmartObjects while another is working on the process definition. However, two developers cannot be working on the same process at the same time.
Merging changes is not supported. Because of the declarative nature of the K2 files, it is very difficult to merge changes based on XML structures. Therefore, make sure that only one person is working on a file at a time.
There is no comparison tool to look at the differences between two versions of a K2 process. You could compare the XML behind the .kprx to look for differences, but this is extremely time-consuming and not intuitive, as there are no visual comparison tools for XML. You could also open the process versions in two different Visual Studio instances and look for changes, but again, this is extremely time-consuming. It is better to enforce exclusive check-outs to ensure that only one person is modifying the process definition at a time.
All of the custom code and modifications made to the process definition are stored within the single
.kprxfile. When you go and modify the code behind an event or rule, that modification and custom code is actually stored within the.kprxfile itself. This is why it is extremely important to back up and enforce proper check-in and check-out of this file to ensure that no changes are overwritten or lost during a collaborative development experience.Never check in extender projects. All information is stored in the
.kprxfile, and checking in extender projects just causes issues.Keep your process definitions in a separate K2 project and solution. This makes it easy for different developers to work on custom ASP.NET pages, SmartObjects, or Service Objects separately from the workflow processes.
If you are working in Visual Studio, the source code management process is fully integrated. However, if you are working on a development team where members are working in other designers (such as the K2 Designer for Visio), you will need to have a developer manually check out the file in order for the team member to be able to modify the process in a designer other than Visual Studio. There is no integration with source code control packages in the other design tools.
Regardless of the technology you put in place to help manage the source code, if the team does not communicate effectively, you will always run into issues. Set guidelines early on, such as having everyone check in their files at the end of the day, and have everyone get the latest versions as soon as they get in the next day before they start working. Or, set guidelines stating that the project must be built locally before being checked in, thereby helping to make sure that the copy in source code control will always be a working copy.
These guidelines should be set at the beginning of the project, and it's a good idea to remind folks often of the rules. Reminders are a good way to keep these guidelines at the forefront of the project team's mind, to ensure that the team works together effectively.
Also, don't rely on the technology to help drive collaboration. Working closely together (literally, having the project team in close proximity) can help the project team be effective. If the project team is virtual, using tools such as e-mail and instant messaging can help bridge the distance. Having frequent checkpoints such as status meetings or central issues lists are also good ideas to help manage the communication between the project team.
The K2 platform's common project framework allows for many design tools and seamless integration between the designers and the project file system. With designers such as the K2 Designer for Visio, the K2 Web Designer for SharePoint, and the K2 Designer for Visual Studio, there is a designer available to match the skill sets on a project team, regardless of the technical abilities. When working collaboratively as a team, it is a good idea to communicate often, manage the project plan, and control the source code and process files using a source code repository. These items will help make the K2 project successful, regardless of the size of the project or team.
In the past several chapters, you have read about how to create processes using the various pieces and components in K2 blackpearl, ending in this chapter with how to collaborate with other process designers. In the next chapter, you will move on to the administration features of K2 blackpearl, including the administration of the K2 server and components.