Policy Workflow Integration Point (Fixed Payload)
This chapter describes the workflow integration point with fixed 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.
Design Principles
If the pend rule is applicable, the pend reason specified on the rule is attached to the policy and the policy pends.
The moment a policy is pended, one or more pend reasons are attached to the policy. If at least one of the pend reasons is configured to cause a notification, that is, if the "publish message?" check box on the pend reason is checked, the system sends out a notification.
The work flow system that receives the event is responsible for assigning the task of resolving the pend to a policies operator. Once the operator has finished working on the policy, then he or she submits the policy for further processing by clicking a button in the Oracle Health Insurance page. This will trigger the generation of a second event, sent from Policies to the work flow system, that informs the work flow system that the pend has been resolved and the task can be closed.
If an operator should submit the policy without having resolved all pend reasons, a task done event is sent out to close the open task. This will effectively also close the task for the unresolved pend reasons, so directly after sending out the task done event, the system also sends out a new event for the remaining unresolved pend reasons.
| Any status transition of a policy out of the pend (edit, cancel or submit) sends out a task done event. |
The following system properties need to be set for the task events URL to be constructed which can be leveraged by an external work flow system to direct the policies operators towards the policy that needs work:
ohi.policies.deeplink.url=http://hostname:port ohi.policies.viewedit.url=/policiesjs/?_ojCoreRouter=view-edit-policies;gid=
The task event is sent in a fire-and-forget mode. That means that once Policies receives the acknowledgment that the notification message has reached its endpoint, no further reply is expected. It is the responsibility of the middleware and/or the work flow management system to handle errors.
New Task Event
Policies sends this event when manual intervention happens before a policy can continue automated processing. A task event contains information on a single policy. A work flow task event has the following structure:
The endpoint to send task event can be configured using 'ohi.workflowtaskstart.endpoint.request' property.
<workFlowTask taskEventId =""
policiesPageURL="">
<workflowPolicy code ="">
<fields/>
<workflowPendReasons/>
<workflowPolicy>
<workflowTask>
The content of the <fields> element:
<field1></field1> <field2></field2> ... <fieldn></fieldn>
The content of the <pendReasons> element:
<workflowPendReasons>
<workflowPendReason
code =""
description =""
priority =""
externalCode=""/>
</workflowPendReasons>
Only pend reasons for which the field 'Publish message?' is checked are included in the task event.
| policiesPageURL refers to the JET Page. |
Enriching the Event
The information returned in an event by default is limited, it identifies the pended policy and the reason(s) why it pended. However, the work flow system that receives these events might require more information to put the task in the right queue. For example, the person’s missing address might be key in determining which policies operator should resolve the pend. In order to support such a situation, an event can be enriched with information from the policy.
The set of information that should be appended to the event depends strongly on the pend reason. Consequently, the pend reason configuration specifies the additional information relevant for that specific reason, in the form of a dynamic logic function. Such a dynamic function defines a list of name value pairs. This list of name value pairs appears in the <fields> element, which is a sub element in the event of a policy.
If a policy has more than one pend reason, then for each unresolved pend reason (with a checked 'publish?' indicator) of the policy, the 'Policy fields function' is applied.
The lists of name value pairs returned by each function will be concatenated to one list within the <fields> element in the Workflow message.
| If the policy has two or more pend reasons that share the same fields function, then it is applied only once. If the concatenated list contains the same name more than once, then only the last instance will be used. |
The function dynamic logic - 'Policy Fields' can also return values to be set as request headers, when specified they are set as request headers of the workflow event.
The following scenarios elaborate on the described enrichment feature. The following pend rules all apply in the policy process step :
Dynamic Logic Function POLICY_MEM_ADD
//Function addressList
Map fieldsMap
fieldsMap = [personCode: policyMember.code
]
return fieldsMap
Function MESSAGE
//Function Message
Map fieldsMap
fieldsMap = [messageCode: policy.message.code
]
return fieldsMap
Suppose policy 1234 is processed. The pend rule triggers; Add_CHECK pend reason is attached to the policy. Based on the field map functions attached to the pend reason, the event is enriched in the following way:
<workflowTask
taskEventId="2134234"
policiesPageURL="http://yourmachine:7002/base.functional/pendRule">
<workflowPolicy code="1234" >
<personCode>123123</personCode>
<workflowPendReasons>
<workflowPendReason
code="ADD_CHECK"
description=""
priority=""
externalCode=""/>
</workflowPendReasons>
</workflowPolicy>
</workflowEvent>
Task Done Event
Policies sends this event when a policy is in a pended status and is either resubmitted for processing or if an operator submits the policy without having resolved all pend reasons. A task done event contains information on a single policy. A work flow task done event has the following structure:
<taskDoneRequest taskEventId="..."/>
The taskEventId is identical to the task event identifier that originally opened the task. As soon as the task done has been successfully sent out, the correlation id of the task event on the policy is cleared. The endpoint to send task done event can be configured using 'ohi.workflowtaskstart.endpoint.request'.
If the workflow endpoint requires Authentication, please use Authentication Use Case: TaskDoneEventClient to set authentication. Please see section Outbound RESTful Service Invocations in Security Guide for the process and more properties.