Articles

How to combine your own custom data with K2 Process information

2008-06-10T14:45:00Z

We have been working with a client recently and as their reporting requirements unfolded it became apparent that the OOB and custom reporting made available through blackpearl wasn’t going to cut the mustard in certain instances.

Why? Well these guys needed reporting that was going to provide them with visibility of information that resides in their own custom data store (SQL Server tables) and also process specific information that blackpearl holds. This information was to be presented via SQL Reporting Services reports and for each instance of a process (submission of a Investment Plan) they needed process information (Folio Name, Start Date, End Date, Duration, Number of times a particular activity has occurred – in this case how many times the Rework activity has occurred) combined with information from their own SQL tables (Customer name, custom Status info and other details). All of this information was available through SmartObjects. The blackpearl OOB reports use their own SmartObjects and we made use of the Dynamic SQL Service to provide the connectivity to the custom SQL database which in turn provides data to our SmartObjects.

Initially our thoughts were to provide the reporting utilizing SmartObjects. SmartObjects are indeed a fantastic component within the blackpearl platform but from a reporting perspective are relatively lightweight. They provide limited “TSQL” functionality, we were to discover that they do not allow for things like aggregation (Select * from SmartObjectA) or Sub Selects which in this case were critical in order for us to produce the information our client needed.

I have raised support tickets for these as I believe they should support this common querying capability.

So we turned our attentions to what was contained within the K2 Databases. Within the K2ServerLog database we looked at the following tables:

_Act

_ActInst

_ProcInstData

Time to take a look at the SQL: We use this piece of SQL to essentially count the number of times a particular activity has occurred in this case the Rework Activity.

SELECT

TEO.Name AS 'TEO Name'

, TEO.Edumis

, TEO.Email AS 'TEO Email'

, TEO.AdUserName AS 'TEO Username'

, TEO.TEOType AS 'TEO Type'

, TEO.XYZArea AS 'TEO Area'

, Activity.Name AS 'Activity Name'

, Instance.StartDate

, Instance.FinishDate

, DataFields2.value AS 'Number of reworks'

, Advisor.FirstName + ' ' + Advisor.LastName AS Advisor

FROM

K2ServerLog.dbo._ActInst AS Instance – K2 Activity Instance table

INNER JOIN K2ServerLog.dbo._Act AS Activity ON Instance.ActID = Activity.ID -- K2 Activity table

INNER JOIN K2ServerLog.dbo._ProcInstData AS DataFields1 ON (Instance.ProcInstID = DataFields1.ProcInstID AND (DataFields1.Name = 'TEOID'))-- Process Instance Data Fields (TEOID). So we have the

INNER JOIN K2ServerLog.dbo._ProcInstData AS DataFields2 ON (Instance.ProcInstID = DataFields2.ProcInstID) -- Process Instance Data Fields (ReworkCounter)

K2ServerLog.dbo._ProcInstData table is essentially a key value pair table per instance for its data fields, with data field name as the key value and data field value as the value data.

INNER JOIN XYZ_IIP_POC.dbo.tblTEO AS TEO ON (CAST(CAST(DataFields1.value AS nvarchar(50)) AS INT) = TEO.TEOID)

INNER JOIN XYZ_IIP_POC.dbo.tblAdvisor AS Advisor ON TEO.AdvisorID = Advisor.AdvisorID

WHERE

Activity.Name = 'Plan Rework'

The Output

This article written by Robin Doddridge and Jian Sun of www.intergen.co.nz

Actions, Outcomes and Lines Left Unruled

2008-05-22T14:15:00Z

In an evolutionary fashion, new concepts have been added to K2 in addition to concepts being changed and refined. To the developer, it means adopting these new and changed concepts to model business processes better. With that in mind, this article addresses a point of confusion that has crept up to which I have fallen prey to. When should you use outcome rules over line rules and how do actions relate to this? The pitfall so easy to fall into occurs when modeling a multiple branching scenario from an activity. If the new K2 concepts have not been understood then where one would expect multiple branches to be followed only one is followed. This is the issue that this article addresses.

Collectively, the three concepts “actions”, “outcomes” and “lines” form the basis of abstracting lower level programming concepts and moving towards higher level concepts that an end user would understand. I am often asked to explain (to both developers and non-developers) the benefits of using a workflow modeling solution like K2 versus just coding it up directly. This article is not meant to be an exhaustive exposition on this matter but I would like to highlight one point to elucidate the “abstraction” concept. The point can be summarized as follows:

In any solution that models a business process, on one end of the spectrum there is the raw code that is written by developers. On the other end, we have business requirements written by business analysts. In the case that we are modeling business processes, the requirements are likely Visio diagrams.

Which is easier to understand (by an end user)? Which is easier to modify? It is of course the business requirements[1].

With these extremes mapped, I would say that K2 sits on the spectrum somewhere close to the business requirements (Visio diagrams) with the opportunity to drop down to the code level if needed; something to please the business analyst and something to please the developer. This is made possible because the concept of a “step” in a workflow has been brought up from the code level to a tangible concept understandable to the computer and something that can be modeled by a business analyst. This is made possible because of abstraction.

Those of you who have worked with K2.net 2003 know that lines and more specifically line rules are not new. They are the logic that represents many lines of code that directs the flow of execution from one step (activity) to another step. In the same tradition of abstraction, there are two new concepts that have been teased out of the code. They are Actions and Outcomes.

Actions

From the workflow, the steps that involves human interaction requires that the human do something or “action” that step. Actions are the options, typically surfaced in a form like “Approve” or “Reject”, that a human can act on a step he/she is assigned that will advance the workflow. . In K2 parlance, actions are defined on each activity that has a client event. This seemingly simple abstraction allows for the following:

· Actions are surfaced up to the K2 workspace which allows a user to action a step right from the workspace, if so desired.

· Actions can be secured. Each action can be assigned a specific access rights from the K2 workspace UI. This allows certain actions to be assigned to some people and restricted from others.

· Actions need not be hardcoded into the “actioning” form. This means that the list of possible actions can be retrieved from the system rather embedding it in form. The advantage of this approach is that the actions in the workflow can change without necessarily requiring the forms to be updated.

Outcomes

Outcomes are a natural extension of actions. Outcomes are formal definitions of a K2 activity that defines the end result of an activity once it has been “actioned”. In many cases, outcomes are one-to-one to actions but they need not be and it is when it is not that things can become confusing. The interesting point is that by design there can be only one outcome followed for an activity. In the one-to-one case, because the user selects one and only one action, it will correspond to one and only one outcome.

In the case that it is not one-to-one, consider the example of a K2 activity:

Actions defined:

· Complete

· Incomplete

Outcomes are not one-to-one and defined as:

1. Complete1: Action = Complete

2. Complete2: (Action = Complete) And (ProductType = Widget)

3. Complete3: (Action = Complete) And (ProductType = Doodad)

For each outcome above there is a line that branches the workflow; lines have no rules so that workflow can branch off in three different directions when the user actions “Complete”.

Because there can be only one outcome, only the outcome “Complete1” will activate. The other two will not be evaluated because an outcome has been found to be “true”.

The first line will be followed, the other two will not.

Outcome definitions must be defined such that only one is evaluated to true. They must be mutually exclusive. The extra clauses (ProductType = Widget, ProductType = Doodad) that I have above that make the outcomes not mutually exclusive should not be defined here. These rules are what control the flow of the process out from the activity. As such they should be defined in the lines coming out of the activity.

To fix the above scenario, there really are only two outcomes, Complete and Incomplete, because this is the set that is mutually exclusive. In this case, because there is no branching with the “Incomplete” outcome it can be removed. The extra clauses that control the branching need to be defined as line rules.

For the branch “Complete1”:

The “Outcome” green variable is a new activity level field that is accessed from the Context Browser:

For the branch “Complete2”:

And for the branch “Complete3”:

When the process is changed so that lines have the rules that control branching then the “expected” behaviour follows.

Summary

This article addresses the issue of when to use outcome rules and when to you use line rules. When this is understood, you will not fall prey to creating a multiple branching scenario that does not seem to follow the defined multiple branches, despite having defined the branching logic.

To summarize the rule of thumb, outcome definitions must be mutually exclusive as there can only be one outcome. Any rules that define the branching from the activity are meant to be defined on the lines and not part of the outcome definition.

[1] Some would argue that because code is exact and prose/diagrams generated by a business analyst is not necessarily clear then code is easier to understand. On the point of ambiguity, there is no questioning that code is exact; that “while (1) malloc (1);” is memory leak and that the business requirement “I want something that can solve my problem well” is ambiguous and open to interpretation. From an end user perspective, however, an end user can be brought up to speed quite fast on a well crafted Visio diagram and would not likely understand code.

Talkin SmartObjects. by Jason Apergis

2008-04-24T17:15:00Z

Background

Colin Murphy, Gabriel Malherbe and I held a workshop on SmartObjects at the K2 Insider Conference this April. It was an interesting discussion because the three of us had some conference calls beforehand where tried to gain a better understanding of how to position SmartObjects in the Enterprise Architecture. I wrote a blog that has not been published which all three of us iterated on before the conference. I made some statements in that article (to invoke debate) where I asserted that SmartObjects could be considered SOA. I got beat up a little by colleagues and now admit that SmartObjects are not SOA even though they adhere to many of the tenants of SOA like autonomy, manageability, discoverable, maintainable, exception handling, scalability, reliability, transactionality, security, logging, build ability, interoperability, testability, etc. Maybe it is low on the maturity scale of SOA (level 2 of 5) and I still debate that sometimes that is good enough for many organizations. It can be challenging to get a company to invest to get to a high maturity level of SOA.

So then what are SmartObjects? Here are some excerpts from the slides that we presented.

Before and Now

In the K2 2003 days we would have to go into the client event after the code was generated and start modifying it to get data from external places. Remember that there is no code generation in blackpearl; it is declarative.

Now all we do is drag and drop smart object references into the canvas to gain access to data; no code.

K2 [blackpearl] Solution

· Blackpearl introduces SmartObjects to solve many of these issues.

· SmartObjects:

o Are reusable business entities which can be deployed centrally and consumed by non-technical workflow authors

o Are a storage location for process data (SmartBox)

o Are a means to quickly access external LOB Data

o Allow developers to aggregate data from multiple backend systems into a single, composite object

o Can be created without writing any code

o Can be accessed outside of the workflow (ADO Provider) and can be reported on

K2 SmartObject in Enterprise Architecture

The following diagram is from a presentation I prepared in November of 2007 for the Texas User Group. At the time I was digging around SmartObjects trying to understand it. From what it looks like my diagram is still spot on.

K2 states that SmartObjects are used to “provision” data into your workflows. K2 uses it as the underpinning to the entire blackpearl platform. The two things you should know right off are there are SmartObject Services and SmartObjects.

SmartObject Services are:

· The providers that access line of business and expose the data through a common interface.

· They expose methods that can be executed; typically CRUD operations.

· They are registered with the K2 Server and instances of them are created through K2 Workspace.

SmartObjects are:

· Class definitions that have data elements that map into the methods that are provided by the SmartObject Service.

· SmartObjects can be graphically used within K2 to access data.

· SmartObjects have a data provider API which you can easily hook into other tiers of the architecture.

In the end SmartObjects is part of your Data Access layer and they allow you to basically write data providers which are access through SmartObjects.

K2 [blackpearl] Solution

The following are out of the box SmartObject Services that are provided by SharePoint.

· SmartBox (cannot be used for custom SQL Databases)

· SharePoint

· Active Directory – I cannot live without this service when building workflows.

· K2 [blackpearl] – Provides easy access to all data that is within K2.

· Salesforce.com

Blackmarket SmartObject Services

The Blackmarket is a K2’s version of CodePlex. It is an area where developers can share code with one another - http://k2underground.com/k2/ProjectLanding.aspx

· Dynamic SQL Stored Procedure Service – Build up Service based on stored procedures in SQL Server. I plan to start using this one because I prefer to be calling stored procedures versus accessing tables and columns directly.

· Dynamic SmartObject Services Service – Build up Service based on schema of a SQL Server instance.

· SharePoint Users in Groups ServiceObject - This ServiceObject when wrapped in a simple SmartObject allows you to leverage SharePoint Groups.

· Office Communication Server Service - The OCS Service Broker allows users to create a SmartObject to send notifications via Microsoft Office Communications Server 2007.

· Dynamic WebService Service– Build up Service based on a web service.

· SmartObject Service Provider for Oracle – Build up Service based on schema of an Oracle instance.

· Dynamic SmartObject Service – Dynamically builds up services that use existing SmartObjects as the data source. The author says this allows you to create SmartObject Service inheritance.

This catalog of services is going grow as more people start to contribute.

Conclusions

The following are my conclusions after the discussion.

· SmartObjects give you a significant edge in delivering timely solutions with K2. They have provided me the ability to immediately access Active Directory, SQL Databases, etc. We have personally seen that we can now deliver working processes in days instead of weeks because we no longer have to build up custom data access layers and go into the code of K2 and manually access the data. I can use the SmartObjects in a drag and drop fashion in line rules, succeeding rules, preceding rules, emails, destination users/rules, any configuration item in any event wizard, etc. It is ridiculously simple to configure my entire K2 process with data and I have zero custom code to get at the data. Plus I can write C# code in custom event handlers to use SmartObject. The API is really clean, simple and similar to using System.Data.

· Another great thing about SmartObjects is that if you carefully take the time to build them you will start being able to build catalogs of SmartObjects that business users can use when composing their K2 Processes. They will not be exposed to any of the details associated to knowing where the data comes from.

· Right now one concern is the ability to place business rules against the SmartObjects methods. For instance if you use the Dynamic SQL Service which build the interface of the service based on the schema of the database there is no way put business rules on the SmartObject to ensure that a value must be greater than X or cannot be null. So if a business user were to use SmartObject Event in their process they could possibly just start setting invalid data.

· The SmartBox is good for doing early iterations of processes but over the long term you may not want to us them. For instance you have limited control over the schema of the database (because it is generated). As well, you may not want to co-mingle data from different processes in the same database.

· Do not let you SmartObjects replace your Data Warehouse. With SmartObjects it is possible to perform CRUD operations across line of business data sources. It is very tempting to have a SmartObject read from many different places providing a single view of the data despite where the data is being read from. A simple example would have a SmartObject read from Active Directory and SQL Server. You must take performance into consideration when doing something similar to this. Performance issues associated to reading data will be vetted out in the SmartObject Service implementation however if you read in two large data sources and then join them together in the SmartObject layer you will not have the opportunity to index those joins. It would be better to have the SmartObject access data in the Data Warehouse itself.

· This comment will be a little at odds with the first but LINQ, Entity and .Net Data Services make it challenging to position SmartObjects. SmartObjects Services may use them to access data and surface it up through a SmartObject for K2. However many developers will be tempted just use LINQ directly inside your custom server events, middle and UI layers. I have not personally messed with LINQ and Entity as much as I should but from the hype it is pretty rich and provide a full Object Query Language and Object Relational Mapping (ORM). The one nice thing about SmartObjects is that they provide you a way to centralize and publish services.

Getting into BizTalk

2007-09-13T04:40:00Z

INTRO

This article will attempt to act as an overview of common message broking architectures, the BizTalk architecture and application, BizTalk components and BizTalk capabilities as a message orchestrator and potential application as a human to human and human to system workflow engine.

The message broker patterns commonly used for system integration are primarily concerned about the transport of data from one system to another.

Figure 1: Message Broker Pattern

The pattern has 4 main components.

Transport Layer: As the source or destination of the data could be anything from a file to a mobile text message, it is the job of the transport layer to pick the data up from any supported proprietary location. The transport layer is not concerned about the structure of the data. It only knows how to speak with the location and the format of the data.

Transformation layer: Once the data’s been picked up, the transport layer will need to understand the structure of the data. Most message brokers will use this layer to transform the data into a common format for internal use. Let’s call this our message

Mapping layer: Sometimes combined with the transport layer, the data, now in a common format, can be remapped and manipulated if needed.

Filtering/Routing Layer: This is the core of the message broker. The idea is that the broker can now route the message out based on the content of the data inside the message. The message could have enough information for the routing engine to determine where it should go and what it should do. Alternatively some work may need to be done to figure this out. This could be achieved by manipulating the message, or by applying complex routing rules and decisions and conditions… from here, the process is exactly the same, but in reverse.

Using this pattern, the BizTalk architecture overview looks like this:

Figure 2: BizTalk Architecture

Want to talk?

BizTalk is primarily a technology for integrating applications. In other words, BizTalk acts as a "broker" between applications, to enable them to work together to achieve a goal, solve a problem or provide extra value. By using a broker approach to application integration you provide a common connection point for these applications and avoid the complexity of custom integration, often significantly decreasing development time. The broker services provided by BizTalk can offer message transport and transformation and increased support for diverse communication mechanisms such as HTTP, MSMQ, FTP, etc. On the Windows platform, using BizTalk in this approach is often the best way to integrate with non-Windows applications, such as AS/400 and mainframes. Various third party adapters are available for BizTalk.

Show me the message!

It’s all about the message. As a message broker, BizTalk is primarily concerned about the transport of messages. It is the main entity in any BizTalk application. By using either the supplier adapters or utilizing third party adapters, BizTalk can pick up messages from a wide variety of sources including FTP, HTTP, MSMQ, etc. The receive pipeline (BizTalk’s implementation of the transformation layer) then converts the message into a known structure (XML as preference). Also here a wide variety of industry standards are supported including flat files, EDI documents, XML, etc. The configuration of ports and the mapping of data in the various pipelines and the optional orchestration a business processes can be done code-free. Current support for different transport and message formats include SAP, Oracle, Siebel and WSS.

Other features include a reliably delivery architecture that ensures that messages don’t get lost. Using a process of dehydration, processing times of messages in BizTalk can be seconds or years with no detrimental effect on the system.

So within this, what can it provide?

Some of the core capabilities are:

· XML messaging through different open Internet standards

· Message transformation/mapping

· Message validation

· Application/system connectivity through application adapters

· Visual business-process orchestration

· Business rules repository and engine

· Support for secure and reliable messaging

Support for long-running transactions

Moving beyond just passing message from one point to another, BizTalk gives a user the ability to graphically define the logic that gets applied via orchestrations for its application integration within the filtering and routing layer. This means that a business process can be dictated inside BizTalk by means of receiving messages, and effectively routing them (or related messages) based on a business process. In BizTalk world this is called orchestration. It can also provide state management and support for longer-running transactions. Building in transformation and or orchestrations is done graphically in BizTalk, and for those trained and knowledgeable, this is a great feature and makes BizTalk powerful yet easy to use.

Is BizTalk workflow?

Define: ‘Workflow’: "The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules." – WMC (Workflow Management Coalition)

Indeed messages flowing from system to system through BizTalk, with rules dictating the routing logic is workflow. However, human-to-human and human-to-system workflow is not always message centric but normally state centric. During human workflow the routing is often based on variety of events and data that we collate into a case. The progression of the workflow normally represents a state change in the case as a whole. Together with that, human workflow requires facilities we as information workers need to effectively and easily interact with a business process.

So what makes human workflow different?

If the bulk of the process is system integration related (transforming, integrating, processing, chunking) and the level of human interaction (making decisions, escalating , displaying data, entering information, tasking, tracking etc) is minimal, a message brokering platform like BizTalk can be leveraged the best bet would be a message broking platform like BizTalk. However, if the primary focuses of your processes are based on human interaction, then a tool set focused on human-to-human or human-to-system processes and workflow would be more applicable. Not doing so could increase the amount of code, time and level of knowledge required to bring these solutions to production and the level of effort required to maintain them. Building processes and workflow with a human-focused platform often makes for easier development and deployment. Some items to keep in mind when considering human workflow the features and intricacies that often become important when building and deploying them:

Task management – How are people assigned tasks based on a business process and how are those tasks managed and escalated?

Task and/or work item notification – When someone is assigned a task, how are they notified? Is the notification mechanism flexible and does it conforms with common collaborative technologies like email or instant messaging?

Work item redirect – Can tasks be easily be re-assigned and routed?

Out of office – How are tasks and work items routed and escalated when the intended actor is not available? Is the actors availability based on some sort of presence notification technology?

Escalations – When work sits on one step, or with one individual, do you want the workflow system to take action, such as send reminder e-mails or escalate the work item to a manager in line with the business process?

Ad-hoc workflow – Informal human workflow and routing used today only have their routes decided at run time. How can the system support this?

Versioning – Human workflows tend to change. How will your system support these changes dynamically and allow for the different versions of the business process to exist at the same time?

Reporting – Human workflows often require the generation of reports and SLA’s based on the business process. This could be based on the meta data of the business case or the people involved in the business process.

Because a message broker platform like BizTalk does not natively address requirements placed on a human business process, accomplishing some of the above can be difficult and cumbersome.

What have we learned and how does that help me?

BizTalk is about applications, systems, messages, etc. Each of these can be called process or workflow, but don’t be confused: This is rarely about interaction with a person, or human, or role. The routing of messages is message centric while human workflow is case centric.

For BizTalk evaluations ask:

· Are my needs primarily message based?

· Do I need to do complex transformations on messages?

· Do I need application integration?

· Are humans going to be involved in this process and what human workflow activities will be required?

Once I have this mapped out, I can start to make decisions on what I need to write (what must I control completely) and what I am going to buy. BizTalk can help greatly in platform- and system- integration scenarios. It excels when you need to connect various systems or applications, especially when they use different communication methods or protocols. If you have simple integration needs, without the need for extensive transformations, and you do not anticipate many other needs of this type, then perhaps coding them manually is the way.

By considering the above, your options range from custom, point to point integration to implementing a robust, industry standard approach with added benefits of orchestration like BizTalk Server. For the automation of business processes that require human task driven execution, consider a human workflow platform like the K2. If a combination of the above is required make sure your human workflow engine and your system integration tool will happily speak to each other.

Where to now?

BizTalk is an information broker for disparate systems. It does not provide data, it does not service data, and it does not expose data. It moves data. So if you need a tool that can easily handle moving data from one format or system to another with built-in capabilities for atomic transactions, and planned roll backs, and the ability to orchestrate a message and system centric process around this, then BizTalk is a sound option.

War stories…

One customer I talked to had custom .NET business objects/entities (like a customer object or a price change object) that they had developed. They also had configured these to be serializable (so you could use them in a Web service where they're represented as XML). The benefit to this is that, in their BizTalk maps, the customer could map the data to the XML schema for the object in question and then just write a single line or two of .NET code to “object.deserialize(xml).” Then they have a fully populated .NET object without doing much at all. This makes creating your Web services simpler, because instead of having to pass in the individual parts, you could just pass in your business object whose parts had been populated for you. This is a good example of a customer that LOVES BizTalk.

This customer says, “For us, BizTalk is a one-stop shop for moving data from one system or format to another with full system-side, non-human-interactive process development flow.” For more human interactive workflow, the purpose of the tools is to better expose and use data interactively — be it decision criteria, expense report data — and have humans interact with it, use it, change it or reply to it.

I would like to take this opportunity to thank all those who helped contribute to this most specifically Gabriel Malherbe, Jeremy Ragan, Bob Maggio, and ChrisT

Automation testing or simulation with K2.net 2003

2007-08-21T22:06:00Z

1. Purpose

This article will show how to create automated unit tests which can be used to exercise K2.net workflow process in both ASP.net and InfoPath. Creating automated testing or simulation with K2.net 2003 may seem difficult to do but is easy when using Visual Studio 2005 Test Projects. Creating unit tests with Visual Studio is no different than creating a custom web page that uses the K2ROM to finish a worklist item that has been assigned to a user. In this case instead of embedding code into an .aspx code behind we are going to put the code into a test method.

2. Create a K2.net Process

The following K2.net process is a standard approve/deny process. This particular screenshot shows an approval process using ASP.net. This process would be initiated by a custom ASP.net page or a K2.net 2003 SmartForm PlanPage. There would then be a second web page which the Manager would use to approve the process instance. Finally an email would be sent out based on the Manager’s decision.

An assumption is made that the reader knows how to create a basic workflow. The specific details of setting destination users, configuring line rules, configuring email, etc. will not be covered.

2.1. Adding a Test ID Data Field

The Visual Studio Test Project will require an identifier to correlate the K2.net process instance with the test instance. K2.net generates an identifier called a Serial Number that uniquely identifies every process, activity and event instance. To achieve this we will add a Data Field to the Process by going to the Properties of the Process, clicking on Data Fields and adding a string type called AutomatedTestID. The value will be generated by the Unit Test and set through the K2ROM which will be discussed later.

2.2. Add Approval Data Field

For the purposes of this article we will add an Approve Data Field to the Manager Approval activity. This will be used by the manager to approve or deny the workflow.

3. Create Visual Studio Test Project

Start Visual Studio 2005 and select File, then new Project. In the New Project window select the programming language of choice (in this case C#) and the select the Test option. Within this select Test Project and place the project in a location.

3.1. Configuring the Test Project

The following will be created for you by default.

First rename the default class UnitTest1 to SimpleWorkflowTest by right clicking the filename in the Solution Explorer and selecting rename. After renaming the file you will be prompted to rename all references; select yes.

Next add a reference to the K2ROM by right clicking the References node in the Solution Explorer and selecting Add Reference. In the Add Reference window select the Browse tab and go to <replace with drive>\Program Files\K2.net 2003\Bin and select the K2ROM.dll.

The resulting project should look like the following.

3.2. Create Test Methods

To simulate this workflow we need to create two test methods. Note the methods must be decorated with the [TestMethod] attribute and the class with [TestClass]. If these are not present neither the class nor its methods will be used when the unit test is executed.

First rename TestMethod1() to SimpleApprovalTest(). Next add two method stubs one called StartSimpleWorkflow() and the other called ManagerApproval(). Notice that both of these methods have not been decorated with [TestMethod] attribute. They will be executed by Visual Studio because SimpleApprovalTest() is the entry point and has the [TestMethod] attribute.

3.3. SimpleApprovalTest Method

Once we have our stub set up, a unique identifier needs to be generated for the unit test instance which will be used to correlate to the K2.net process instance. Modify SimpleApprovalTest() to generate a GUID and pass that value down into both StartSimpleWorkflow() and ManagerApproval().

[TestMethod]

public void SimpleApprovalTest() {

//Create Test Instance GUID

Guid testInstance = new Guid();

//Start the process

StartSimpleWorkflow(testInstance);

//Give K2 server time to create process instance

System.Threading.Thread.Sleep(2000);

//Approve the process

ManagerApproval(testInstance);

}

Both of these methods will need to have their signatures modified to accept the GUID.

private void StartSimpleWorkflow(Guid testInstance) {

}

private void ManagerApproval(Guid testInstance) {

}

Note the System.Threading.Thread.Sleep(2000) was added to give K2.net server a little time between activities. Depending on your testing server performance, this value may need to be modified or this line could be completely removed.

3.4. StartSimpleWorkflow Test Method

Add the following statement using SourceCode.K2ROM; in the class.

Add the following code to the StartSimpleWorkflow(Guid testInstance) method which will create a new process instance using the K2ROM. This method opens a connection to the K2.net server, sets the GUID to the process instance and folio name, and finally starts the process.

private void StartSimpleWorkflow(Guid testInstance) {

string connectionString;

string k2Server;

string processName;

Connection conn = new Connection();

try {

//Recommend moving thses values to app.config file

connectionString = "CONNECTION STRING";

k2Server = "SERVER NAME";

processName = "SimpleApproval\\SimpleApproval";

//Open K2 Connection

conn.Open(k2Server, connectionString);

//Create Process Instance

ProcessInstance process = conn.CreateProcessInstance(processName);

//Set the test instance id

process.DataFields["AutomatedTestID"].Value = testInstance.ToString();

//Set K2 Folio Name

process.Folio = "Test Simple Approval " + testInstance.ToString();

//Start the process

conn.StartProcessInstance(process);

}

catch (Exception ex) {

// failed validation

Assert.Fail("The process failed: " + ex.Message);

}

finally {

conn.Close();

}

3.5. ManagerApproval Test Method

In this method a connection is made to the K2.net server and the Worklist for the Manager is opened. This is done by using the WorklistCriteria object to query for the WorklistItem that has test instance GUID set in its process data field. This is done by using a WorklistCriteria with a filter. When the WorklistItem is returned the activity instance data field is set to “approve” and the WorklistItem is subsequently finished.

private void ManagerApproval(Guid testInstance) {

string connectionString;

string k2Server;

Connection conn = new Connection();

Worklist workList;

WorklistCriteria workListCriteria = new WorklistCriteria();

try {

//Recommend moving thses values to app.config file

connectionString = "CONNECTION STRING";

k2Server = "SERVER NAME";

//Open K2 Connection

conn.Open(k2Server, connectionString);

//Retrieve the test manager's worklist items

workListCriteria.AddFilterField(WCLogical.And, WCField.ProcessData, "AutomatedTestID", WCCompare.Equal, testInstance.ToString());

workList = conn.OpenWorklist(workListCriteria);

//Find the worklist item with the test identifier in it

foreach (WorklistItem workListItem in workList) {

//Set the process for approval

workListItem.ActivityInstanceDestination.DataFields["Approve"].Value = "Approve";

//Finish the worklist item

workListItem.Finish();

}

catch (Exception ex) {

// failed validation

Assert.Fail("The process failed: " + ex.Message);

}

finally {

conn.Close();

}

3.6. More Test Methods

More test methods could be created in a similar fashion. For instance a similar test method could be created for the denial path. As well if the workflow had multiple steps every step in the process could have a method created and chained to one another to fully test the entire workflow and every possible path it could take.

4. Deployment

It is highly recommended that this not be done on a production K2.net server. A K2.net testing server should be used to run the unit tests on. The reason is that these test process instances will be intermingled with production instances. Having these instances in there will subsequently throw off or dilute reports provided in the K2.net Workspace.

Deployment of the SimpleWorkflow would be the same as any other K2.net process using the Export functionality in K2.net Studio.

5. InfoPath Testing

It is possible to test InfoPath process in K2.net visual studio as well. In the Visual Studio Test Project, add a reference to the InfoPathService web service.

Change the StartSimpleWorkflow(Guid testInstance) method and remove all of the code associated to the K2ROM. Instead call the SubmitInfoPathData method of the InfoPathService web service. Generate the XML for the InfoPath form and pass that into SubmitInfoPathData webmethod. To get a sample of this XML, open an InfoPath that has been K2.net enabled and save it locally. Then open the .Xml file in a text editor and copy the Xml into the Visual Studio. That Xml string can be passed into SubmitInfoPathData.

Next in ManagerApproval(Guid testInstance) remove the following line of code.

workListItem.ActivityInstanceDestination.DataFields["Approve"].Value = "Approve";

Instead use this line of code to retrieve the XML for the InfoPath Form.

string infoPathXml = workListItem.ActivityInstanceDestination.XmlFields["K2InfoPathSchema"].Value;

Once the Xml has been retrieved, modify it (setting it to Approved) and call SubmitInfoPathData webmethod again passing in the Xml. Do not set the Xml back into workListItem.ActivityInstanceDestination.XmlFields["K2InfoPathSchema"] because this would not accurately test the process as InfoPath will always call the web service.

6. Conclusions

Very sophisticated testing processes can be done in this manner testing multiple steps and every permutations of the workflow. Load testing can be done as well by creating multiple unit test instances to identify bottlenecks in the workflow process. Bottlenecks could be sometimes be hardware specific, a connection to an external system may be too slow, tables in a database require indexes, etc. Using this methodology it is possible to completely test your K2.net processes without writing any ASP.net or InfoPath front-ends. This will create a highly decoupled solution and is considered a best practice.

This article was written by Jason Apergis from RDA Corporation. You can find out more information about them below:

RDA Corporation

RDA provides business and technology solutions through custom application and software development for all types of companies. Our experienced staff employs a proven process to help our clients reduce costs, improve results, increase profitability, reduce time to market, develop new business opportunities, mitigate risks, and increase efficiency.

RDA specializes in .NET and Java solutions in the areas of business intelligence; communication and collaboration; enterprise application integration; mobility; operational efficiency and productivity; portals; and security.

RDA is a Microsoft Gold Certified Partner in Business Process and Integration, Custom Development (Web and Application Infrastructure), Data Management (Business Intelligence), Information Worker, and Mobility solutions. In addition, RDA has been named Microsoft Partner of the Year four times: for Microsoft's East Region in 2007, for Microsoft's Southeast District in 2007 and 2005, and for Microsoft's Mid-Atlantic District in 2004. This award is presented to the partner having the greatest impact on Microsoft’s business with metrics based on partner services revenue, engagement volume, and customer satisfaction. A winner of Microsoft’s Integration Solution of the Year award, RDA is also a part of Microsoft’s Virtual Technology Specialist Program as well as a go-to partner for Microsoft’s Enterprise Service Bus offerings.

RDA has developed innovative technology solutions for a broad and diverse client base since its founding in 1988. Detailed case studies organized by industry, solution and technology type reside on our corporate website at www.rdacorp.com. Headquartered in Baltimore, RDA also has offices in Atlanta, Charlotte, Philadelphia, Seattle, and Washington, DC.

Moss and Workflow Security

2007-07-12T04:01:00Z

There are numerous ways of setting up and securing your MOSS environment from server hardening to IPSEC and SSL. Going through all of these are not the focus of this article. However this article will go through an overview of Moss. Next I will go into the security model, give an overview of the permissions and how they operate, including touching on what’s new. I will provide you with a matrix of the permissions, permission levels and groups to help you plan your security options. Then I will give you details on how to customize permissions and break free from the default permission inheritance. Then I will go into how all that we have gone over will affect workflow, including starting, participating and reporting. Then I will provide some wrap up and summary to ensure a complete picture is had.

So What is MOSS

“Microsoft Office SharePoint Server 2007 is the successor to SharePoint Portal Server 2003 which provides server capabilities such as comprehensive content management , enterprise search, and collaboration. MOSS also provides professionals and developers with a solid platform to take advantage of and build MOSS based applications or extensions.

What’s new in MOSS from a security perspective?

Good

1. Better 3 Tiered security Model

2. New more extensive permissions.

Better

1. Central administrators no longer have full access to content. (however they can take ownership, but then would be audited and logged)

2. Rights Masking. Administrators can remove certain rights from even being available to site administrators to grant. Such as “Manage Alerts”

Best

3. Security Trimmed user interface. If you don’t have rights you don’t see it!

4. ITEM LEVEL GRANULAR ACCESS

To better understand security in MOSS let’s talk about the basic security Model that makes up MOSS. MOSS now has a true 3-tier administrative model. This is going to make things easier for organizations to separate portions of administration and roles. The 3 tiers are 1. Farm Administration 2. Shared Services administration and 3. Content administration. As shown in (figure 1)

Overview of MOSS security Model

Figure 1.

The Layers

Farm Administration

Those who are in this role are responsible for the maintenance of all servers that make up a designated farm. Members of this group have the rights to perform all tasks in the Central Administration website. It is important to note that this group will not have access to the sites or the content inside them by default. However it is possible for members of this group to obtain these rights through the administrative interface by adding themselves as a site collection administrator. However this action will be audited and logged and provide for a evidence trail if this access was inappropriately used. Another important note for farm administration is that by default the local administrators group can perform all administrative tasks and more including deploying new applications, or web parts, and, creating additional web applications. However as with Farm Administrators they have no access to content without explicitly taking action.

Shared Services and Shared Services Providers(SSP):

First off what is SSP?

SSPs are for managing a set of services such as searching and indexing, my site hosting, Usage Reporting, Excel Services, and Business Data Catalog Configuration
The SSP administration interface is a Site
An SSP by default is a separate web app from the other web apps extended with SharePoint Technology
SSP administration is not available with WSS

SSP administrators can control which services are included in a Shared Services Provider (SSP) and configure settings for those services. Example tasks can include

· Configurable portal usage reporting

· Configuring permissions for specific services such as search, Excel services etc.

Content: These are all your site collections, sites, lists, document libraries etc.

Administration at this level is made up of Site collection administrator and Site Owners:

Site collection administrators: Members of the site collection administrators group will have full Control permissions on all web sites within a site collection. This means that they have access to content in all sites in that site collection, even if they do not have explicit permissions on that site.

Site owners: By default, members of the Site owners group has the full Control permissions on that site. They can perform administration tasks for the site, and for any list or library within that site.

Keep in mind that every site collection is an island of security. What I do in my site collection will not affect your site collection. By default a child site will automatically inherit the permissions of its parent. Unless the permission inheritance is stopped and that site “breaks free” which I will speak to shortly.

For general site content the site administrator should assign appropriate permissions within the site to various document libraries, lists, wiki’s etc. If the security model is such that there are people who maintain specific lists it would be their job to further restrict and maintain permissions for their various list items. By default all lists and libraries will inherit the site permissions, however the list owner can then further restrict or open up access based on need.

Another aspect of administration and rights is the Web Application. While the web application level does not have a dedicated “Web Application Administrators” group however Members of the “Farm Administrators” in addition to those local administrators do have the ability to define a “Web application policy” to grant people access at this level. Be careful with granting this because adding in people in at this level does give them access to the content contained within that web application.

So how do permissions work in MOSS? Lets Identify some common security terms and concepts.

Permissions: These individual permissions (of which there are 33) will grant a certain ability to perform specific actions. As an example Edit Personal User information, this right once granted will allow the granted user to modify their own user information such as updating their picture. In addition the list or possible permissions that can be granted can be “masked” so that they are unable to be granted to any user.

Permission Levels: These are essentially a defined set of permissions to perform related actions. For example the contribute level contains many rights such as Add items, Edit Items, Delete items and others. For a complete matrix see figure x. Similar permissions can be included in numerous levels and the existing levels can be customized to meet the needs of the environment. However I would recommend creating new levels rather than editing the default out of the box levels. Each of these permissions levels are also inheritable to child sites.

User: This is a person that can be authenticated through whatever authentication provider that is available, in MOSS you are no longer restricted to AD. These users can be assigned permissions levels by themselves or they can be part of a broader group that gets assigned certain permissions levels. Going the group route is a far better choice.

Groups: This is a collection of users. A group in the SharePoint context can be a SharePoint group such as “Site Owners” or can be an Active Directory group such as “Accounting Department”

Securable Objects – The above mentioned users and groups are going to have certain permissions levels for a specific securable object: such as a document library, a task list or any SharePoint item. By default these permissions are automatically set to inherit from their parent site. This can be changed however be very careful when doing this as it adds more administrative overhead. There are some new securable objects available to administrators in MOSS they are

· Website

· Lists

· Libraries

· Folders

· Documents or files

Getting into the permissions themselves in detail, hopefully the permission matrices in the following sections help in planning your strategy. There some additional new permissions available to be used.

New Permissions:

Permission	Comments
Approve Items
Delete Versions
View Versions
Open Items
View Forms Pages	Turned off by default for publishing features in Office “12” Server.
Create Alerts
Use Remote API’s	Turned off by default for publishing features in Office “12” Server.
Manage Alerts	(was manage Subscriptions)
Browse User Information
Create Groups	(Was create cross site groups)
Manage Permissions	(Was manage Website)
Open Container	Allows users or groups to open the parent site of a list/library or the parent list/library for a folder or item/document so that they can view the list/library or folder or item/document to which they have been granted access. Required for fine-grained permissions

Permissions to Permissions Level Matrix

Permission/Permission Level	Full Control	Design	Contribute	Read	Limited Access	Approve	Manage Hierarchy	Restricted Read
List Permissions
Add Items	X	X	X			X	X
Approve Items	X	X				X
Create Alerts	X	X	X	X		X	X
Delete Items	X	X	X			X	X
Delete Versions	X	X	X			X	X
Edit Items	X	X	X			X	X
Manage Lists	X	X					X
Open Items	X	X	X	X		X	X	X
Override Check Out	X	X				X	X
View Application Pages	X	X	X	X		X	X
View Items	X	X	X	X		X	X	X
View Versions	X	X	X	X		X	X
Site Permissions
Add and Customize Pages	X	X					X
Apply Style Sheets	X	X
Apply Themes and Borders	X	X
Browse Directories	X	X	X			X	X
Browse User Information	X	X	X	X		X	X
Create Groups	X
Create Subsites	X						X
Edit Personal User Information	X	X	X			X	X
Enumerate Permissions	X						X
Manage Alerts	X						X
Manage Permissions	X						X
Manage Web Site	X						X
Open	X	X	X	X	X	X	X	X
Use Client Integration Features	X	X	X	X	X	X	X
Use Remote Interfaces	X	X	X	X	X	X	X
Use Self-Service Site Creation	X	X	X	X		X	X
View Pages	X	X	X	X		X	X	X
View Usage Data	X						X
Personal Permissions
Add/Remove Private Web Parts	X	X	X			X	X
Manage Personal Views	X	X	X			X	X
Update Personal Web Parts	X	X	X			X	X

	Full Control	Design	Contribute	Read	Limited Access	Approve	Manage Hierarchy	Restricted Read

Regular website
Approvers					X	X
Designers		X			X
Hierarchy Managers					X		X
Quick Deploy Users					X
Restricted Readers					X			X
<Site> Members			X
<Site> Owners	X
<Site> Visitors				X
NT AUTHORITY\Authenticated Users					X


Central Administration
Farm Administrators	X
BUILTIN\Administrators	X				X

Shared Service Provider
There are no SharePoint Groups in the SSP. Default just the (domain) administrator.	X				X

One item to point out after reading these matrices is what “Limited Access” is. Limited Access is required for any user to use/view the common items that cross all we sites such as the various navigation bars, themes etc. This is truly the base permission level, and is fairly meaningless unless you are granted other permissions.

To summarize how permission work in MOSS You will have Individual permissions such as Manage Alerts. Then you also have Groupings of permissions for common roles such as contributor which includes several individual permissions that are common to a role. Then you can have Roles such as Member, Owner, Visitor that are assigned these permissions groups. You can modify and customize these in order to effectively grant and maintain effective permissions you must first understand the permissions and when each are assigned based on the default groups and permissions levels. When planning these permissions you can use the appropriate matrices you can use to better understand this.

Now that you have seen all of the permissions, and roles and have a general understanding of how these pieces work the next item to discuss is how to break away from the default permission inheritance to set your own permissions on a specific securable object.

Breaking Away

With the heavy inheritance model in MOSS administrators need to have a way of blocking this process. Administrators can through the use of “Breaking away” prevent the inheritance from the parent and set a new set of permissions in their securable object. So If I have a sensitive list or library contained in a more open site I can restrict the access to my list or even child site by breaking away the permissions from my parent and not allowing it to inherit the base level of permissions, and only have the permissions I want. In figure 2 I have clicked on edit permissions and am warned of the effects.

Figure 2

The fantastic part of breaking away is after I break away I can easily re-join by clicking on “inherit permissions” in the drop down menu. A great way of testing and rolling back. As shown in Figure 3

Figure 3

How does all this affect workflow in brief?

Since workflow in MOSS is primarily List, and document library based administrators need to plan appropriately and make sure that users who will be participating in workflow have enough permissions to effectively participate in the workflows but not too many rights that they can inappropriately take action and or effect workflow when they should not(Least Privilege principal). Administrators need to be aware of how security affects users ability to not only participate in workflow, but also initiate the workflow, create new workflows, view currently running workflow and view history reports on workflow. One item to keep in mind is that if you are going to be using SPD or the office client integration anywhere you will need to assign the following 2 permissions to anyone that will interface in that way.

· Use Client Integration Features

· Use Remote Interfaces

Let’s go into some of the details about each area of workflow and break each function down.

Security for workflow participants

Simply participating in workflow can require different permissions based on the workflow type and what actions they may need to take. However for most workflows involving the usual list or document library item. Workflow participant should have at least the following rights

· Edit Items

· View Items

· Open Items

· View Application Pages

· View Pages

· User Remote Interfaces

· Use Client Integration features –Required if doing workflow through office clients

· Open

Fortunately the “Contribute” permission automatically provides all of these permissions which is part of the Site\Members group. However this permission level also adds a few more such as

· Delete

· View Versions

· Delete Versions

· Create alerts

· Browse Directories

· Use Self Service Site Creation

For this reason some organization may wish to create a specific permission level, based on a more restrictive need. I highly recommend for at least for your confidential workflows to create your own History Lists and possibly even task lists. As an user that can “View” items in a list I will have the access to both view the tasks that everyone is working on as well as run reports on currently running or historical workflows, even if I was not part of that workflow. You will find it very difficult to modify the permissions on the default workflow history list. This is another great reason to have MOSS create a special list just for that workflow. See figure 4 below for a screenshot.

Figure 4

Starting and Participating in workflow

Essentially the same permissions that allow me to participate in a workflow will also allow me to kick one off that has already been associated. Weather this is from the SharePoint web interface or the office client interface For some additional security requirements It is possible to require the “Manage Lists” permission to initiate workflow by selecting this option during association as shown in figure 5.

Figure 5

If I have “design” or greater rights I have the ability to impact workflow even if items are not assigned to me. For example if I have these rights and browse to a workflow in process. I will be able to add additional people to the workflow, add comments, or even cancel it. Simple contribute rights will not allow this to happen so give out design rights as sparingly as possible. However even with full control permission I would not be able to “approve” an item if it were not assigned to me.

Reviewing workflow items

Members can see task items and look at their details even if they are not assigned to them. Visitors can see the task item but cannot open unless they are assigned that work item. Basically what this can mean is they can see what workflows are running, who they are assigned to the dates and descriptions. In many cases this won’t mean much but in some it can, so it should be planned for.

Redirecting

Delegating or redirecting a workflow is part of the configuration options for each workflow as seen in figure 6. When planning also be aware that the person who is being re-directed to will need appropriate rights. So when planning the use of workflows you should plan these rights appropriately.

Figure 6

Completing Tasks

Completing one’s own can be done even with visitor rights by default. There should be no additional rights necessary.

Creating and or Associating New Workflow

Before one of the Out of the box workflows can be used in document library or list, that workflow must first be associated with that library or list. However for those workflows created with SPD the association is done automatically. In order to associate workflows you need the designer level or if desired you can use contributor level and add the additional right of manage lists. This will now expose and make functional the workflow settings item in the list or document library settings. However some organizations may not want to give these rights to all those that may ask for them. It may be best in these cases to appoint a “workflow” role that can be assigned or delegated by the “Site Administrator”. Another option is to create a custom permissions group that would include the necessary rights at not only the Library or list level but also for the site level. This is because even if you have full control over the list or library, you may not have the rights to associative workflow with that list as this is a site level right.

Those with the Full Control permission in a specific site or the Manage Website added to the design level can connect, and modify or create workflows via the SharePoint Designer interface. Most organizations will place those with the need to use SPD to customize sites with the owner role. When this is the case, you can prevent them from modifying certain document libraries or lists by modifying the permissions “Breaking Free” and not inheriting from the site. Once this is done if they don’t have rights they will not even be able to see it in SPD.

Workflow reporting

By default even visitors of a site can access the workflow history list and run reports which are done through excel. This is a great reason to create dedicated history lists and restrict rights to them.

Workflow Tasks

Site visitors will still be able to see all tasks, however they would not be able to open any of them to see what their contents are. Those with member rights will be able to look through each items. Those with contribute rights will even be available to open the task items and action them even if they are not assigned to them.

Wrap Up

Now that you have an idea of what is required and hopefully have some idea of the permissions needed. Will the default levels, groups and permissions fit your organization and how your users work? My guess is that they will work as is for a significant amount of customers out there. However their certainly are valid reasons why you would not only want to create additional permission levels but also additional groups. As an example if I have specific workflow needs that may be of a more sensitive nature I need to make sure that only those with a need to know have access to view ANYTHING about that workflow or the data within it. I would need to make sure that no one even had read writes to the list itself. I would also want to create a dedicated task list and history list to ensure complete security/confidentiality.

Let’s take a look at how this would work.

if you were setting up a workflow for an HR group and the content of the document and or the comments etc should not be viewed by anyone other than a specific few. Restrict the rights on the library, create a new workflow associated with that doc library and have it create a new workflow history as well as a dedicated task list, as shown in figure 7.

Figure 7

Next take the new history and task list, break it free from inheritance and apply new permissions to it restricting the permissions. Now you have a more secure workflow and can be assured a more advanced level of confidentiality in these workflows.

Conclusions

So by now hopefully this makes some sense to you, there are a lot of little nuances based on different situations and you security and workflow needs. I feel that it is necessary to give a short wrap up/summary to ensure the core concept here is clear. What this can boil down to is a few points

1. If you have a site where you there is workflow being utilized through MOSS and there are no special security or confidentiality concerns special permissions will probably not be necessary.

2. If you have a site where there are possible confidentiality concerns where some members of a site should not be able to participate or see information contained in some specific workflows.

3. There are new rights that can be assigned in MOSS administrators should take some extra time to determine if the default permissions and groups are appropriate for their needs.

To Moss or Not To Moss

2007-07-11T18:04:00Z

Intro

What is workflow

According to the workflow management coalition workflow is defined as:

"The automation of a business process, in whole or part, during which

documents, information or tasks are passed from one participant to

another for action, according to a set of procedural rules."

In the real world workflows are rarely "simple" and are usually made up of several individual and logical steps each of which are known as an activity. These activities can have human involvement or might just be a piece of work a machine is responsible for. The workflows themselves will involve both human and system involvement and will also involve various branching, splitting and joining of the numerous paths taken in a process. Don't be scared away, automating and managing a work process can provide huge returns in efficiencies, and will drive process improvement on a regular basis.

What is Microsoft doing in Workflow?

Workflow Foundation (WF)

For developers, and ISV's Microsoft has introduced Windows Workflow Foundation as part of the .Net framework version 3 Windows Workflow Foundation a programming model/ framework for building workflows into your applications. The goal of WF is to provide a general framework that supports workflow, and make it a standard part of the Windows environment.

Microsoft Office SharePoint Server (MOSS)

The office team has seen a significant advantage in leveraging WF and hosting it inside of the SharePoint process to facilitate new functionality. For the 2007 release of SharePoint,(MOSS) Microsoft had a goal of providing an infrastructure that would drive work processes around what SharePoint does best: share and collaborate on documents. With this in mind you will see that there was a focus on document-centric workflows, processes that a particular document needs to go through during its lifecycle, such as being reviewed and edited or being approved for publication. With SharePoint in 2007 you can attach and run a process directly on a SharePoint document or list item. Companies will begin to evaluate MOSS both for its tremendous out of the box web capabilities, as well as for some workflow capability newly introduced into the latest 2007 version. Microsoft has heard the plea of its customer base and implemented workflow into the SharePoint platform. Essentially what the office team has done is built on the work done by the Workflow Foundation team and extended it as well as provided a host process for it. So not only do you have some out of the box workflow, if you have the development skills to do so, you also have the ability to code your own workflows utilizing WF and deploy them to the SharePoint server leveraging its host process.

Moss Workflow Out of box

Microsoft has built and is hosting some common workflows that will be shipping with MOSS, these workflows are easily configured and usable upon installation of Moss. We will touch more on these in a bit.

SPD

SharePoint Designer(SPD), will be released as part of the Office suite of products replacing the long standing FrontPage as the web designer. SPD can be used to create workflows that will be hosted in MOSS. Again more on this functionality and what to expect later.

Office Client

The office 2007 client supports and integrates with workflow right out of the box. Providing a somewhat seamless workflow interaction ability with the workflows that run in your MOSS deployment. This is a fantastic ability that will greatly increase the use of and success of workflows being deployed in a Moss environment.

Workflow Keys to success

Before you start to make a decision on where workflow and MOSS fit into your organization you need to figure out what your true needs are,

How complex are your workflows?
Who will be building these workflows?
Where will your data live?
How much detail do I need in auditing, and reporting?
What interfaces do I need?

Without knowing the answers to all of these you will be unable to make a valid decision and may spend valuable time and resources going down a path that will not end with the result you desire. It is worth the time to sit-down with the stake holders now and figure out what your real needs are longer term and choose the right tool for the right job.

If you want a process based effort to succeed you must think about your users first.

How do your users work?
What tools do my users use? (IE, MySites, SharePoint, Outlook, LOB App)
How do my users get their information?
How do my users do their processes now?

Keeping these in mind while building a process or application will dramatically increase the adoption and success rate of your effort. Try and force users to do it differently or throw a cultural curve ball at them and you are asking for users to find a way to bypass this new and more efficient way of doing things.

Now What?

So the questions that get asked over and over again is what should I be looking to do in SharePoint either out of the box or though the SharePoint designer, and when am I going to either have to breakout Visual Studio and start writing custom code, or look to the ISV community for a more extensive workflow solution. How do I evaluate what it can do for me and at what point am I going to start building and supporting the code.

Let start by walking through some evaluation criteria.

1. When I think about my workflow what interfaces and interactions am I looking to use.

Basic WebPages?

InfoPath forms or InfoPath forms rendered through the new Forms server?

Do I need to solely use the interfaces provided through the Office clients?

These amount to some serious decision criteria for several reasons. From a probability of success stand point, think about which interfaces are best for your users. From a technical standpoint if I am building workflow through SPD my only choice is to use the ASP.net forms that SPD generates for me when building out the workflow. My ability to customize or re-host these forms is limited. The OOB workflows however do use InfoPath forms , and can use the rich features provided through the office clients if I am using Office 2007, which provides a very attractive option if my workflow needs are simple. However if I am like most organizations who sees deploying office 2007 as a more distant goal my options can be more limited. Thus I am left looking to building the workflow using Workflow Foundation.

2. Where does your data live?

This is perhaps the most important question in this decision process. Quite honestly if the answer is not SharePoint you are in most cases going to do some significant coding. Once you have determined this now you have to consider whether, you will write your own host process or will you be able to leverage the integrated functionally given in MOSS. In this scenario the answer is the same. If my data does not live in SharePoint you are going to be better served by building your own or buying one.

3. When you think about your workflow needs what other systems are going to be involved.

a. If you are integrating into other systems such as ERP, CRM or other back end applications, you are going to have to breakout Visual Studio and start writing custom code, or look to the ISV community for a more extensive workflow solution, as there is no ability either through the OOB workflows nor the SPD interface to interact with backend systems in a meaningful way. MS does allow some data to be surfaced through the use of the BDC which will provide me with a read only list type copy of back end data. You do have the ability to take this data if exposed in your site and leverage it in a workflow, however this data is read only.

4. What type of business logic will you need to have to run or determine the flow of your processes?

a. Complex if this then that.

b. Simple and straight forward.

c. How much conditional branching or parallel processing would be involved?

With regards to the OOB workflows your ability to add any type of business logic, or branching and converging is non-existent. This capability was not their focus when building them. Also be aware that you take the out of the box workflows and add to them. So you move on to SPD, and while SPD does support the base concept of If else type branching if you need to leverage complex business logic you are most likely going to be going back and developing these with custom code via the Visual Studio interface. However if your workflows do not contain this requirement and the logic behind them is straight forward the OOB or SPD type workflows will be able to provide good value.

In the same vein you need to think about how this business logic is determined

Is it based on data that is a critical part of the workflow Such as meta data associated with a document or based on user input values. Both of these really bode well for using MOSS and SPD etc. However many organizations base most of their workflows on External Data and as stated previously this makes your effort more difficult.

5. What other key items/features do you need to make your workflow efforts more successful?

a. Escalations

Escalating a workflow either at a individual step or as a whole is limited to sending email reminders at a given point in time. This may work great for some groups whose workflows are not tied to an SLA, or other critical functions. However you may see a need to develop in more advanced escalations such as automatically redirecting the workflow to a different user or group of users, or taking some kind of custom action. If this is the case for your organization you will be back at a building or buying.

b. Time zones

Does your workflow require accommodation of people in different time zones? This mainly takes on additional importance with time or business processes. These should be less common in the SharePoint world but will probably still exist. I am currently not aware of any way to accommodate this so if this is an area of importance to you, creating your own workflows and possibly host is going to be a consideration.

6. What level of auditing and reporting is necessary to effectively manage and improve processes?

a. How much do you need to know about the process, who was involved and how do you need to track and store progress. Once you store it how long do you need to keep it? The level of reporting that is involved with both the OOB workflows as well as those created with SPD, are great for their purpose. It will tell me when a process started, who was involved and other basic information. Advanced levels of reporting are not available in the OOB workflows and do not provide a great deal beyond what you would find in SPD. Other methods should be considered if this is an area of great importance.

b. Security

Microsoft has done a great job in increasing the granularity and flexibility of the security model in SharePoint. This has obviously been extended to include workflows and the various applications you build on top of that platform. However there is a part of workflow in its management of tasks that does have a shared aspect. In high security environments this may be a concern.

7. Does my SharePoint site design and architecture match a design necessary to meet my workflow needs?

a. Since workflows are site bound are the workflows that you will be creating isolated enough to meet this requirement, or do I need to have workflow actions that cross site, application, and or portal boundaries. If this is the case, you will need to leverage the Visual Studio interface to make this happen.

Lets look further into how we create and use MOSS workflow.

SharePoint Designer and Workflow

So what can you do with SPD? Workflows are created by specifying conditions and actions through what can best be described as an outlook rules type design interface. For workflow I can check for the presence of certain conditions and then take actions either based on those conditions or without condition. SPD does have the ability to create multiple steps, with different conditions, and actions including support for such things as "If then else" type logic.

Benefits:

1. Workflows can be created very quickly

2. Deployments are not complex and can be executed quickly

3. Can be created by non development focused people

4. Risks from deployments are minimal because of the trusted list of conditions and actions.

5. Created from a finite list of conditions and actions, trusted by the system and its administrators, making the creation of workflow easier.

Drawbacks and limitations

1. Actions are site bound to the site they are run from.

2. Still need to have IT skill sets, cannot be done by normal Business Users

3. Limited support for advanced complexity and scope in building out workflow.

4. No re-use capability, is authored against a specific list of document library cannot then be used again on another list.

5. No ability to modify in flight.

6. Must use ASPX pages.

7. Limited customizability of these ASPX forms.

8. Cannot be accessed directly from Office 2007 applications, must be accessed with a web browser other than through email notifications etc.

SPD Conditions

Figure 1

Some conditions to check for are as follows:

1. With Specifics words in the title or other fields

2. Modified (either in a specific time window or by a person)

3. Created by or in a specific time frame

4. File type

5. File size

6. ADVANCED Condition(Custom condition)

Actions

Figure 2

The action tasks for example are as follows:

1. Create task

2. Update task

3. Delete task

4. Send email

5. Prompt for values

6. Change Item Status

As a developer you also have the ability to publish your own custom actions through the use of Visual Studio and the published SDK for workflow and MOSS. So in practice what does this mean to you? Lets explore a popular workflow example I have seen. A popular use of MOSS and the surrounding workflow will be primarily document-centric. With that in mind let's say I am a knowledge worker who is responsible for a specific set of document libraries in side of a SharePoint site. I want to create a workflow attached to a document library that when initiated will perform certain actions such as copying that document to another library or sending an email to certain groups based on the type of document it is or values contained within the documents metadata.

So what I can do is use SPD to attach to the document library and create a workflow similar to the following

Conditions

Condition Create by = HRGroup

And

Condition words in Title = Human Resources

Action

Send Email to HR Policy Group

Assign Action to HR Policy Group

Copy Document from current Document Library to Policy Review Library

Else

If created by administrator

Email HR Group

Collect more information.

Figure 3

Some caveats on this workflow. Both document libraries must reside on the same site, and the metadata the workflow is trying to evaluate must be guaranteed to be present. So some careful planning and configuration needs to take place.

MOSS Out of the Box Workflows

Microsoft is shipping several workflows that will be present "Out of the Box" They are tentatively as follows:

Approval: Routes a document for approval. Approvers can approve or reject the document, reassign the approval task, or request changes to the document.
Collect Feedback: Routes a document for review. Reviewers can provide feedback, which is compiled and sent to the document owner when the workflow has completed.
Collect Signatures: Gathers signatures needed to complete an Office document. This workflow can be started only from within an Office client.
Disposition Approval: Manages document expiration and retention by allowing participants to decide whether to retain or delete expired documents.
Group Approval: Similar to the Approval workflow, but uses a designated document library and offers a personalized view of the approval process(es) in which a user is participating. This workflow provides a hierarchical organization chart from which to select the approvers and allows the approvers to use a stamp control instead of a signature. This solution was designed specifically for East Asian Markets.
Translation Management: Manages document translation by creating copies of the document to be translated and assigning translation tasks to translators.
Issue Tracking: Manages the issue tracking process by creating tasks for Active issues assigned to users who own to a given issue. When the task related to an issue is complete hence resolving the issue, the creator of the issue is assigned a review task so that the issue can be closed.

Benefits:

1. Pre-made workflows you can just configure and go.

2. Based solely in the office environment, no custom gui to learn or deploy.

3. Ability to change parameters during execution, such as add more approvers, redirect to a different approver, and request changes from the originator.

Drawbacks and limitations:

1. Each workflow is site bound, so no actions such as creating task or copying document can take place outside of the site that it is running on

2. These workflows cannot be extended or significantly modified since they are compiled DLLS on the SharePoint server.

I believe that organizations using SharePoint 2003 today will really like the collect feedback, issue tracking and Collect signatures workflow, they provide a simple yet effective workflow that automates some very common tasks found in corporate America. However with these workflows and how they assign manage and display tasks, even with the roll-up tasking, the task management of the workflow may be difficult to be truly applicable in larger more diverse deployments or in matrix organizations..

Many organizations with a more mature SharePoint deployment that is in high use will find adapting these OOB workflows as well as SPD workflows especially as the Work Flows themselves begin to cross organizational boundaries or groups. However organizations who are not afraid of development work and maintenance will be able to overcome this hurdle. Those with a Build mentality will find this a fresh approach to building applications on a good platform.

Workflow integration and Office client 2007

This really is the best feature area for how and when you want to leverage MOSS and workflow. Being able to store a office document in a document library and start and interact with that workflow right from the office application itself is a powerful tool in the workflow users and builders arsenal. Figure 4 represents the option from the new office menu for starting workflow. Figure 5 is a screenshot of how tasks will appear in the office application itself where there is one for that document. Figure 6 is how you are able to choose which workflow to start from within the office application.

Figure 4

Figure 5

Figure 6

Who will build it and will they come?

Who will build, deploy, and manage your workflow? Organizations planning on implementing not only MOSS with WF or any workflow applications need to seriously consider this among other questions. There are some serious design considerations with determining these roles. With SharePoint designer organizations must place the creation and deployment of workflow in the same role. There is no way that I am aware of to have one person go through and create the workflow then send that application to another for the actual deployment. With this being said there are some obvious security implications but more so than that there are some trust and cultural issues in many organizations that need to be overcome. However from a security perspective the IT risk should be minimal as was discussed, since the impact is constrained to a specific list and the actions being taken are restricted to a minimal set. Obviously this can be changed with IT creating and exposing additional actions to be surfaced in the designer. However from a default perspective this is not the case.

Many organizations today, are beginning to see the value in involving the business community in a more proactive role for application/process/workflow design. There is a tremendous amount of value in making a significant effort to do so. The values of which go beyond the scope of this article . However, if organizations are going to attempt to tap into this value they will need to seriously consider the basic technology skill set present in the users they are looking to involve. While SPD is not a developer experience where one needs knowledge of API sets and similar terminology it does however need in most cases more skill sets than the average end user possess. This is because it introduces workflows and the like in a manner that these types of users are not used to thinking of. There is terminology, ways of thinking and planning that make this effort slightly prohibitive. However as stated this can be overcome with some training. If this does not seem appealing to you, there are alternatives in the ISV community.

Wrap up.

What does all this boil down to? Microsoft has made great leaps forward in adding value to those organizations that choose to invest in MOSS and already have investments in SharePoint 2003. Even if you take workflow out of the picture MOSS provides a huge amount of value. Organizations that choose to leverage the abilities of MOSS for workflow or choose to use it as a platform to develop their own applications will be pleasantly surprised at the plumbing provided. Before going down the path of workflow every organization will need to look carefully at their needs and what amount of effort they are ready to put forward into meeting those needs before moving forward into a workflow project.

If you have looked at MOSS, SPD, and WF and these do not meet your needs, please take a look at K2 which leverages these technologies but makes for a collbaborative environment for your business users and IT developers.

Workflow Design - Spider Workflow

2007-07-11T01:09:00Z

A number of people have asked me to explain the 'Spider Workflow' approach to workflow design, so I thought it would be best to blog about it. So here goes...

1. Introduction
There are a number of design cases in workflow solutions, where the 'order of steps' is now known or cannot be determined at design time. An example of this is where certain steps might occur more than once (eg: a specific manager needs to keep reviewing a document until conditions have been met), or where the user is involved in determining the next step of flow of events (eg: A user might wish to route a document directly to the regional manager (instead of the departmental manager).

Frequently during these types of solutions, the workflow designer attempts to solve this by linking each workflow step to each of the possible next steps in the process. This, however, can result in a very complex spaghetti workflow process with lines linking everywhere. There, in order to clean up this 'ad hoc' style workflow, one of the possible solutions is the 'Spider Workflow' approach.

2. Spider Workflow Approach
Spider Workflow is a workflow design approach in which the workflow gets handled by a central 'router' hub step, and a number of single 'spoke' steps. Using this approach, the workflow design is centered around an 'intelligent' central hub step, that determines which step (or steps) the workflow should route to next. (The spider workflow design could also (probably more accurately) be described as a 'hub-and-spoke' design). During the workflow runtime, the process will get routed from one spoke to another, until a specific condition (flag) is met such that the workflow is complete. In this manner, any spoke can follow a previous one (even the same spoke more than once if required).

3. How is it Built (Refer to the attached diagram below)
Referring to the diagram, the spider workflow is implementing using the Routing Step as the central hub. This is an activity that contains a single Server Event that evaluates data in order to set an 'Outcome' data field. Each line that emerges from the Routing Step contains a simple line rule that checks the value of 'Outcome' to establish whether it needs to be followed or not. (Example: the line that runs from Routing Step to Manager Approval could have a line rule that checks whether "Outcome==Manager Approval", and if yes, the Manager Approval would be the next step.

This can continue indefinitely until an 'exit condition' is met (depending on the solution). An example of this would be (referring to the diagram) the process might need to continue, once all of the 4 parties (Manager, Finance, Regional Manager and the CEO) have approved a specific doc. In this case the Routing Step would evaluate the Approval data fields, and if all 4 of them are set to 'Approved', then it would simply set the Outcome to 'Continue' (and potentially this would make the process continue to the Process Continues step)

4. Spider in Action (An Example)
Lets take a look at this in action. The originator might submit a new 'Policy Doc' and the process starts. By default the process has been built that if the user doesn't specify who this should be routed to next, it follows a default order (Manager -> Regional -> Finance -> CEO). Therefore, the doc gets routed to the 'Manager Approval' step.

The Manager takes a look but feels that the policy is too expensive, so he/she specify on their UI that the task must get routed to 'Finance Review' next. The Routing Step evaluates the data fields set by the Manager, and routes the task to the 'Finance Review' step.

The Finance team are happy with the doc, so they approve it, but do not specify a specific next step. The 'Routing Step' checks the default order, notices that the Manager has already approved, and the next default person is the Regional Manager, so then it gets routed to the Regional Manager.

The Regional Manager is happy with the doc, but he/she sees from the process history that the Manager routed it directly to Finance with some concerns. Therefore, the Regional Manager adds some additional comments, and routes it back to the Manager to review the doc.

The Manager gets the doc (for the 2nd time), sees the approval history and comments, and is now happy with the doc, and approves it again. The Routing Step now determines that the only person that has now seen the document is the CEO, so it gets routed to CEO Approval.

The CEO has a look, sees everyone else is happy with the doc, and approves it.

At this point, the process reaches a specific condition where the 'Routing Step' evaluates all the requirements and establishes that everyone that needs to approve the doc has already done so, so the workflow is routed to 'Process Continues' (where the doc might be uploaded to SharePoint, and the originator notified etc etc).

This is just a simple run-through of a single instance, however, it should be apparent that this process can be approved in any order, and number of times, all dependant on the conditions coded into the 'Routing Step' server event.

5. Extending the Design
This design can be taken a lot further than the simple scenario painted above.

5.1 Multiple Concurrent States
It is relatively easy to extend this solution to allow multiple concurrent steps in the workflow. There is no reason why this document cannot be reviewed by the Regional Manager and by Finance at the same time. One simple needs to add additional code/flags so that the Routing Step knows what to do in these circumstances. Fundamentally the process can get as complex as required, and the exit condition will always be 'if all confitions have been met, the process can continue'

5.2 IPC
Extending the design further, the spoke steps could be IPC (Inter Process Calls) to sub-processes. The only downside is access to the data, where the 'call-by-value' data passing to the child process means that child processes can only get/set their local copy of data fields that only get bubbled up to the parent upon completion of the child process. One can work around this problem by using SmartObjects that can be accessed from anywhere.

5.3 Mixed Model
The spider workflow is not an absolute workflow design. Any workflow process could at any stage include a 'spider-style' section, and it can therefore be used in a mixed model with classic (sequential) workflows, or even with other spider workflows (eg: where a spoke is effectively a hub for a sub-region). It all depends on the scenario.

6. Conclusion
To some degree, the 'Spider Workflow' approach has been over-hyped as the silver bullet for ad-hoc workflow. Basically this just a logical approach for flexible workflow design, that is very hard to report on (due to the vast number of activity (specifically routing step) instances) which makes it more difficult to measure the metrics of the solution.

Authored by Olaf Wagner