HOME COMMUNITY BLOG
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

The workflow is sequence of steps, performed by the workflow engine, when executed. The sequence of the workflow is made of tasks or blocks. Tasks can consume the data stored in context stores defined for this workflow.

Attributes

StartRule

Defines a rule, which is evaluated before the task is performed. If the rule returns

  • True – The step is executed
  • False – The step is skipped

StartRuleContextStoreContext store upon which the start rule is evaluated.
EndRuleDefines a rule, which is evaluated after the step is finished. If the rule throws any exceptions, the containing block is stopped from performing. If no exceptions are throwed, the workflow continues with next steps.
EndRuleContextStoreContext store upon which the end rule is evaluated.
TraceRead only. True if data about execution of this step are recorded to the trace log for debugging purposes.
TraceLevel

Specifies how data about execution of this step will be recorded to the trace log for debugging purposes.

All steps have InheritFromParent set as default, so e.g. if you turn on tracing on the workflow or one of its blocks, all steps will inherit this setting and will be traced.

OutputContextStoreDefines a context store, to which any output data will be merged after the step is finished. E.g. which context store will get filled by the data returned by data service.
OutputMethod

Specifies how data will get merged into the OutputContextStore:

  • Ignore: Any output data will be ignored and no context will be updated when task finishes.

  • AppendMergeExisting: Any updates to the existing data will be updated, using the entity primary key. Any new data (not found in the original context by primary key) will be appended to the context. No data will be deleted from the context.

    This method is default for the Service Method Call task, because e.g. data transformation will typically return subset of the XML data, so they can be updated in the context. If FullMerge would be used, all missing data would get deleted.

  • FullMerge: The context will get updated the way, that it will contain exactly only the data returned by the finished task. Data found by primary key will get updated, data not found by primary key will get inserted and data which exist in the context but do not exist in the data returned by the task, will get deleted from the context.

 

This method is default for the User Interface task, because users are allowed to do any updates to the data, including deletions. It is intended that the context shows exactly the same data after editing, as the user saw on the screen, thus full comparison and merge must be performed between the data returned from the task and the context.

 

Trace Levels

None

Nothing will be recorded.
InheritFromParentDefault. Data will be recorded only if parent steps specify that data should be recorded.
TraceArchitectData will be recorded only if the workflow is executed from ORIGAM Architect. This is important when you want to debug workflows but you do not want other users, running ORIGAM Desktop Client, to interfere into your trace log.
TraceClientAndArchitectData will be recorded always. This is important e.g. if you cannot reproduce a bug but your customers can. You turn this option on and after the user reproduces the behaviour, you turn tracing off and analyze the trace log.

Task Types

  • No labels