How do manual actions work

[Steve O]

I have a simple work flow I want to implement:

Rest API receives an acces request and launches an approval workflow.

First step is gather the list of approvers for the request

Second step is wait for approvals from the approvers (assuming manual here)

When an approval is received determine whether the minimum set of approvals has been received and shift to approved (normal state), do something when the request is approved and shift workflow to end state.

When a dental is received, do something and then shift to the end state.

My question is the part about how to handle receiving approvals. (Assume I am using a Rest API to expose the approval submission).

How does one inject this approval into the sleeping workflow and trigger some sort of evaluation on the current state for further automatic processing?

[nflow-users]

Hi,

Your second step can be a normal step with nextActivation in future. In the state method, check from some external system/storage if the minimum set of approvals has been received. If yes, proceed in your workflow. If not, schedule the same state again in future.

Your Rest API implementation should store the approval somewhere where it can be checked by the workflow. It may optionally wake up the workflow instance when a new approval is submitted to avoid the delay while waiting for the next activation.

Please also note that it is not the best practice to update state variables outside the workflow state methods, because nFlow may then overwrite the changes if it is executing a state method while the state variables are updated.

Hope this helps.

br, Edvard

[nflow-users]

Hi,

Forgot to add that you can wake up the workflow instance using either nFlow Java API (WorkflowInstanceService.wakeupWorkflowInstance, if you have nFlow embedded in your Rest API app) or nFlow Rest API (v1/workflow-instance/{id}/wakeup).

br, Edvard

[Steve O]

Hi Edvard, 

Yes, I think I see the pattern here.  I had expected that the manual step meant to instruct the workflow to go to sleep, and then wake on some external event like being provided new approval objects, but that is not the pattern.  It would seem that there is fundamentally no difference between a normal and a manual step except perhaps how they appear in the workflow graph. Is that a correct interpretation?

Thank you for the help, and might I suggest that your team consider providing more example workflows that demonstrate the full suite of state types in your code base?

Cheers

Steve

--
You received this message because you are subscribed to the Google Groups "nflow-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nflow-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nflow-users/c9a892ec-c6a2-4b28-aa41-4267c57241a6n%40googlegroups.com.

[Steve O]

I am attaching a diagram of the state machine.  I found something on line that shows how to execute a manual shift using external update but when this happens the updated diagram shows a red arrow bypassing the manual state and the manual state does not appear in the activity history.

[nflow-users]

Hi,

The main differences between normal and manual states are that normal states must have state methods that return NextAction that tells nFlow engine what to do next. Manual states do not need to have state method at all, and even if they do, they can't return NextAction, so nFlow engine will always stop processing that workflow instance (until the instance is manually moved to another state).

Please check io.nflow.tests.demo.workflow package for some example workflows. If you think there is something essential missing, you could open an issue to nFlow Github and we will look into it.

About your example, it would help if you could provide your workflow definition code (you can remove your business logic, the state definitions and the constructor are the interesting part). Anyway, looks like you moved directly from newRequest to checkApprovals. Does you newRequest state method move to awaitApproval state immediately? Was newRequest state processed by nFlow engine before you moved the instance to checkApprovals state?

br, Edvard

[Steve O]

This is just a pilot so I don't mind sharing.  Attached is the workflow definition sans business logic.  I am also attaching the application rest controller and app file.  Intuitively it would seem that manual steps ought to be able to accept an input from an external source.  When I look at the workflow histories I don't see an entry moving from manual state to next normal state, it looks like the manual state is bypassed completely.

This workflow should 1. Start when an access request is received and figure out who the approvers are and update the request status.  2. Wait for external changes (events, signals etc) to receive approvals.  3. On each approval event determine whether the minimum set of approvals has been received.  4. Shift to denied if an approver denies the request.  5. Shift to approved once all approval criteria is met otherwise shift back to waiting for approvals.

To view this discussion on the web visit https://groups.google.com/d/msgid/nflow-users/c317e355-1958-4e7c-9ef0-d6a7cf7112bdn%40googlegroups.com.

[nflow-users]

Hi,

The manual state is not actually bypassed, it just looks like that in the action history, because the manual state does not have a state method that would create an action.

But looking at your workflow definition, I don't really see why you would need that awaitApproval state at all. Instead of moveToState(State.awaitApproval, "..."), I would just moveToStateAfter(State.checkApprovals, DateTime.now().plusMinutes(10), "...").

I would also use workflowInstances.wakeupWorkflowInstance(requestStatus.workflowInstanceId, asList(State.checkApprovals.name()) instead of updating the workflow instance manually. It will work better if the nFlow engine is executing a state method at the same time you are trying to update it, and it will also not put the workflow instance back to checkApprovals state if it was just moved to a final state by nFlow engine.

And finally, I would remove the DemoAccessWorkflow.REQUEST_ID state variable, as it is already store as the external ID of the workflow instance.

br, Edvard