...
Examples of non-repeatable workflows are often used in AppFacets.
Jira Legacy |
---|
showSummary | false |
---|
server | JIRA (mqidentity.atlassian.net) |
---|
serverId | 77fb3325-4051-36d9-bcc7-761f62050707 |
---|
key | DOCS-36 |
---|
|
Code Block |
---|
language | xml |
---|
title | Non-repeatable workflow example |
---|
linenumbers | true |
---|
|
<AppFacet name="CSVLoader">
<String name="destModelName" />
<String name="DriverId" />
<String name="ParkingLotId" />
<String name="fileName" KnownBy="csvLoaderAc" Update="auto" />
<Action name="csvLoaderAc" documentation="Data Facet to load CSV Data">
<Workflow Limit="1" Live="1" Timeout="-1">
<Task name="Main">
<Event name="Argument" as="ActionArgument" />
<Invoke name="CSVDataLoader" waitFor="Argument">
<FacetScript>
<Log Message="Loading file..."/>
<LoadFromCSV fileName="[%:Event.Argument.fileName.Value:%]"
destModelName="[%:Event.Argument.destModelName.Value:%]"
DriverId="[%:Event.Argument.DriverId.Value:%]"
ParkingLotId="[%:Event.Argument.ParkingLotId.Value:%]" />
<Log Message="Loading complete!!!"/>
</FacetScript>
</Invoke>
<Output name="ActionResult">
<Value>
<Log Message="Output file name: [%:Event.Argument.fileName.Value:%]"/>
<fileName>[%:Event.Argument.fileName.Value:%]</fileName>
</Value>
</Output>
</Task>
</Workflow>
</Action>
</AppFacet> |
...
Instances of such workflow are started right after they are created. This is done by ensuring that all the input values of the workflow's initial task(s) have their values assigned in your source code (versus waiting for external events to give value). They are only useful if they are doing something or communicating with some other entities [en-masse] which is difficult with non-repeatable workflows. Jira Legacy |
---|
showSummary | false |
---|
server | JIRA (mqidentity.atlassian.net)serverId | 77fb3325-4051-36d9-bcc7-761f62050707 |
---|
key | DOCS-36 Code Block |
---|
language | xml |
---|
title | Example of non-waiting workflow |
---|
linenumbers | true |
---|
|
<Action name="SetOutput">
<Workflow Limit="1" Live="1" Timeout="-1">
<Task name="Step1">
<Input name="Argument" type="string" kind="literal" value="Hello World!"/>
<Output name="Result" type="string" value="Step1 says '[:Input.Argument:]'"/>
</Task>
<Task name="Step2">
<Input name="Argument" type="string" value="Step1.Result"/>
<Output name="Result" type="string" value="Step2 says that '[:Input.Argument:]'"/>
</Task>
<Task name="Step3">
<Input name="Argument" type="string" value="Step2.Result"/>
<Output name="Result" type="string" value="Step3 says that '[:Input.Argument:]'"/>
</Task>
<Task name="Step4">
<Input name="Argument" type="string" value="Step3.Result"/>
<Output name="Result" type="string" value="Step4 says that '[:Input.Argument:]'"/>
</Task>
</Workflow>
</Action> |
...
These are workflows which have explicit “event handler”. Instances of these workflows wait for the external event to come and then start ("external" here means external to the workflow itself). The "event handler" is written as "Event" in the workflow definition. In ThingFacet (and AppFacet) workflows, the Event is typically the ActionArgument, which is triggered by the modification of actionable attributes of the model facet. Jira Legacy |
---|
showSummary | false |
---|
server | JIRA (mqidentity.atlassian.net)serverId | 77fb3325-4051-36d9-bcc7-761f62050707 |
---|
key | DOCS-36 Code Block |
---|
language | xml |
---|
title | Example of externally-activated workflow |
---|
linenumbers | true |
---|
|
<Action name="SetOutput">
<Workflow Limit="1" Live="1" Timeout="-1">
<Task name="Step1">
<Event name="Argument" as="ActionArgument" />
<Output name="Result" type="string" value="Step1 says '[:Event.Argument:]'"/>
</Task>
<Task name="Step2">
<Input name="Argument" type="string" value="Step1.Result"/>
<Output name="Result" type="string" value="Step2 says that '[:Input.Argument:]'"/>
</Task>
<Task name="Step3">
<Input name="Argument" type="string" value="Step2.Result"/>
<Output name="Result" type="string" value="Step3 says that '[:Input.Argument:]'"/>
</Task>
<Task name="Step4">
<Input name="Argument" type="string" value="Step3.Result"/>
<Output name="Result" type="string" value="Step4 says that '[:Input.Argument:]'"/>
</Task>
</Workflow>
</Action> |
...
These have an invoke with the WaitFor modifier. Instances of such workflows can start, work for a while and then suspend and wait for an event in the middle of task (on the waitFor). Once wait is completed they continue until the next WaitFor or process completion (The "external" here means external to the workflow itself). Jira Legacy |
---|
showSummary | false |
---|
server | JIRA (mqidentity.atlassian.net)serverId | 77fb3325-4051-36d9-bcc7-761f62050707 |
---|
key | DOCS-36 Code Block |
---|
language | xml |
---|
title | Example of externally-continued workflow |
---|
linenumbers | true |
---|
|
<Action Name="SerialReadAction" Documentation="Start the serial port">
<Workflow Limit="1" Live="1" Timeout="-1">
<Task name="Main" while="true">
<Event name="Argument" as="ActionArgument" />
<Invoke name="InvokeSerialRead" waitFor="Argument" get="perif://">
<Message>
<Value>
<InterfacePort>
"[%:Event.Argument.interfacePort.Value:%]"
</InterfacePort>
<Baudrate>
"[%:Event.Argument.baudrate.Value:%]"
</Baudrate>
<Interface>
"[%:Event.Argument.interface.Value:%]"
</Interface>
<UniqueId>
"[%:Event.Argument.uniqueId.Value:%]"
</UniqueId>
<Operation>
"[%:Event.Argument.operation.Value:%]"
</Operation>
<format>
"[%:Event.Argument.format.Value:%]"
</format>
<Payload>
"[%:Event.Argument.payload.Value:%]"
</Payload>
<Peripheral>
"[%:Event.Argument.peripheral.Value:%]"
</Peripheral>
</Value>
</Message>
</Invoke>
<Log
Message="Invoke --> [%:Invoke.InvokeSerialRead.Message.Value.received:%]" />
<Output name="Result" as="ActionResult">
<Value>
<tempValue>
[%:Invoke.InvokeSerialRead.Message.Value/number(
substring-before(substring-after("[%:Invoke.InvokeSerialRead.Message.Value:%]",
'#TCB:'), '#')):%]
</tempValue>
</Value>
</Output>
</Task>
</Workflow>
</Action>
|
...