IT:AD:K2:Concepts

(UP)
- IT:AD:K2/Concepts/Best Practices

[TODO] Ask for clarity from Lee Evans

Contains n Activities, which in turn contain n Events
Also referred to as a Process.

* Contains n Events

Can be a Client/Server event.
Note that when you drag a Workflow Event from the K2 Toolbox to the K2 Designer, it immediately wraps it in a 'Workflow Activity', so it's difficult for first timers to see the difference between an Activity and an Event.
But it becomes easier to spot when you add 2 or more Workflow Events to the same Workflow Activity.
A Workflow Event can optionally contain Line Rules
Note that IT:AD:K2/Concepts/Best Practices suggest that for each individual Workflow Events within Workflow Actions, one should
- Clearly name them
- colorize them:
  - Orange = Server Event
  - Blue = Client Event
  - Yellow = IPC Event
  - Grey = Web service or Integration call
  - Red = Process End point
  - Green = Process Start
### Workflow Actions ###
are the decisions made
Can be controlled by rights

* Are invoked by Workflow Actions/decisions as long as they pass the Rules associated to the Outcomes. * In other words, One can have a Submit Action that is mapped to two different Outcomes, one with a Rule defining Amount>=1000, and the other Amount<1000.

Interconnect Activities
Contain Line Rules that by default evaluate to true.
Colourize:
- Green = Approved
- Red = Declined
- Blue = Send for Rework

* Empty/Undefined rules evaluate to true. * Precedence/Order in which the Line Rules are applied is:

Line Rule
Preceding Rule
- It is the if rule: if evals to true, then procceeds to Start Rule.
Start Rule
- It is the when rule: determines when the Activity will start.
Destination Rule
{all events}
Succeeding Rule

* Types of Escalations:

Process
Activity
Event

[TODO] Need Lee Evans to clarify this part

* A single instance of a Process [Template]. * [TODO:Verify description with Lee]

A preceding rule is not a „wait until this is true‟ type of rule. The only remaining question is when it will start, and that then gets determined by the Start rule. Another way to think of this is that a Line Rule, when evaluating to True, leads to an activity. The activity then executes the Preceding Rule, which is used to evaluate data to determine if the activity should continue. If Yes, then the Start Rule fires which contains a time-based logic to determine when the activity should begin. The process is dehydrated and another thread is responsible for rehydrating the process at the appropriate time according to the Start Rule calculation, which takes into account the configured Working Hours. It is important to remember that a non-configured (empty) rule will always evaluate to True, so when you do not have data-based or time-based requirements for starting an activity, the activity will automatically start when the line leading to the activity is complete.

Data Fields:
- Process Data Fields:
  - Lifecyle: Exist for the entire lifetime
  - Scope: global to the process.
    - Data fields should only contain data that are tightly related to the particular business process or activity that they are defined for.
      
      eg: business entity ID's etc.
    - Recommend against containing data displayed in the UI layer.
    - Activity Data Fields:
    - Lifecycle: Exist for the lifetime of the activity instance
    - Scope: scope of the activity instance.
    - In K2.net 2003 activity data fields are duplicated for each destination user assigned to the activity. For this reason irresponsbile use of data fields can easily consume large amounts of server memory, network bandwidth, and possibly also disk storage.
    - In K2 blackpearl the default setting for activity destination rules are to Plan just Once, and by default the data fields will not be duplicated in the same way.
      
      However, it is still possible for a process developer to change the destination rule to plan per destination, and in such cases data fields will be duplicated for each destination user.
    - XML:
    - used to store data about a process, eg: SharePoint integration data, workflow
    history, actual InfoPath forms for those types of processes, etc.
Serial Number:
- To notify the workflow the event is complete a key piece of information must be made available to the external system: the serial number of the activity containing the asynchronous server event. Every activity (whether you use it or not) has a serial number that uniquely identifies it.
  - A serial number is similar to the correl ation ID in used
  in message queuing. This serial number allows you to use the K2 API to open the correct server item and complete the event using the Finish method of ServerItem:

A Workflow Definition,
that can be deployed many times (each definition getting it's won ProcessId ),
that can be launched many times, each instance getting it's own ProcessInstanceId.

Each workflow is a set of many Activities, each containing 1-* Events within it.

Therefore to each ProcessId instance definition one gets several ActivityId (definition) entries. Each time it is run (ie, a ProcessInstanceId is generated) a new set of ActivityInstanceId's are created.

`Workflow 1-1 ProcessId 1-* ProcessInstanceId` `ProcessId 1-* ActivityId` `ProcessInstanceId 1-* ActivityInstanceId`

By default there is a 1-1 mapping between Outcomes and Actions
- Actions are the decisions made
- Outcomes are the results of those decisions
Separating the two:
- allows modification of processes without designing Client events.
- allows autogeneration of line rules
- allows rights to be associated to Actions
  - allowing dynamic display of only Actions they can use.

K2 is several servers:

Category Server:
- TODO: Describe better
Workflow Server:
- TODO: Describe better
Workflow Management Server:
- TODO: Describe better
ServiceObject Server:
- TODO: Describe better
SmartObject Server:
- TODO: Describe better

BP is to store data using SmartObjects, outside of the K2 process. That said:

Process Data Fields
- Lifecyle: Exist for the entire lifetime
- Scope: global to the process.
  - Data fields should only contain data that are tightly related to the particular business process or activity that they are defined for.
    - eg: business entity ID's etc.
  - Recommend against containing data displayed in the UI layer.
  * Activity data fields:
- Lifecycle: Exist for the lifetime of the activity instance
- Scope: scope of the activity instance.
  - In K2.net 2003 activity data fields are duplicated for each destination user assigned to the activity. For this reason irresponsbile use of data fields can easily consume large amounts of server memory, network bandwidth, and possibly also disk storage.
  - In K2 blackpearl the default setting for activity destination rules are to Plan just Once, and by default the data fields will not be duplicated in the same way.
    - However, it is still possible for a process developer to change the destination rule to plan per destination, and in such cases data fields will be duplicated for each destination user.

If the Workflow has > 15 Activities, it's a good candidate for being reworked into smaller workflows connected by IPC.
- That said, splitting it up makes it a lot harder to report on coherently. Consider that carefully.
Check *.kprx file. If it is > 10Mb, consider breaking it down to smaller units.