Policy Workflow Integration Point (Configurable Payload)

This chapter describes the workflow integration point with configurable payload in context of policies.

A policy may be pended for manual intervention in certain circumstances, for example, if the person on the policy has different addresses. This is done by setting up the pend rules. The pend rule describes the circumstances in which a policy pends while the pend reason describes why the policy has pended.

When a policy pends, the system sends out a workflow event, if at least one of the pend reasons needs to be published to an external system, that is, the 'Publish Message' indicator on the pend reason is set to 'Yes'. In the external system, this typically results in the creation of a task to be dealt with by an operator. The event itself will hold the required information for both routing and task creation purpose.

The information sent out in this workflow event includes information to support routing and task creation/assignment in the external system ~ typically a workflow system. This information includes both configuration information present on pend reasons that apply, as well as additional information relevant for that specific reason, in the form of a dynamic logic function.

A pend reason sends a workflow message in the following scenarios:

  • If the system property "ohi.workflow.start.logic.request" has no value, the fixed payload functionality is used. See Policy Workflow Integration Point (Fixed Payload) for more info.

  • If the system property "ohi.workflow.start.logic.request" has a value, then:

    • The dynamic logic with the code equal to the value of the system property is called and the result is used to invoke the workflow system. If the dynamic logic does not exist in the system, then the workflow system does not start and notification is not sent.

    • If the system property "ohi.workflow.start.logic.response" has a value, then the dynamic logic is called.

    • If the system property "ohi.workflow.start.logic.response" has no value, nothing is done with the workflow system’s response.

  • If the system property "ohi.workflow.end.logic.request" has a value, then:

    • The dynamic logic with the code equal to the value of the system property is called and the result is used to invoke the end workflow system. If the dynamic logic does not exist in the system, then the end workflow system does not start and notification is not sent.

For the workflow to be successful, set the following property as follows, else the workflow will fail.

ohi.service.ConfigurableWorkflowEventClient.client.authentication = None

Design Principles

OHI applications use workflow to trigger a human action when the automatic processing detects the need for it. Typically, this starts by the run of a pend rule.

If the pend rule is applicable, the pend reason specified on the rule is attached to the policy and the policy pends.

When a pends happens, the processing of the business objects halts and a message is sent to a workflow system. The workflow system ensures that the task gets assigned to an operator. From the workflow system the operator can deep link into the relevant OHI screen and do the required action. Once the operator submits the object for further processing, the OHI apps sends a "task done" event to the workflow system, so the task in the workflow system gets closed.

WFCS supports the handling of such pends as follows:

  1. Start a process (task) when an OHI app sends a workflow start message.

  2. Route the task to a particular user (group) based on the pend reason.

  3. Open the OHI page from the deep link URL that was sent with the workflow IP message.

  4. Close a task once a task done message is received.

Example Processing Flow

The below steps explains the example flow when the configurable workflow payload is integrated with Oracle Process Application (OPA).

  1. A policy gets pended during processing. As soon as this happens, the Start Workflow Request Dynamic Logic is invoked.

  2. The response is processed. To process the response the Start Workflow Response Dynamic Logic is started to extract the taskId generated by the external system. This value is stored internally as the taskEventId in policies.

  3. The task flow is started over and the workflow task is ended. For this, the End Workflow Request Dynamic Logic is invoked, passing the processId (=taskEventId) as input.

For more information on the above workflow system signatures , see Pend Reason.

The methods that construct the message to be sent to the workflow system may need information about the current pends. That information is not included in the signature, in order to keep the signature as simple as possible. The necessary information can be retrieved by calling a predefined method.

For more information on the predefined methods for policies, see getWorkflowPendReasons.