Prepop Data |
|
|
|
|
|
Prepop Data |
|
|
|
|
Prepop Data |
|
|
|
|
|
Prepop Data |
|
|
|
|
|
|
||
So, when you have the work flow defined, you can then create the pre-population data. Composer wants this data in XML
When the collaboration service is actually running, the pre-population data sent back to the form is on the work flow data related to the particular work flow step in operation. The TM service does not send all the work flow data for security: we don't want malicious parties hacking the form's HTML and reverse engineering the work flow procedures in order to circumvent them.
For that reason, you will have to define the sets of pre-poluation data, one set each for each of the workflow states that require the use of the form. We have worked through the Standard 2-Tier Work Flow example for you. You use these data sets to test the visibility of whole sections and individual form elements as well as other rules and properties. Part of the challenge of collaboration is to get the form to behave properly at each of the work flow steps, and the better the working order of the form while it is still being built in Composer, the better.
In Composer, you paste in your fake prepop data into the "Preview Data" panel, which you access in 2 locations:
•"Structure Panel -> <Top item of the structure tree> -> Edit Properties -> Policies -> Preview Data -> Prepop Data Content"
or
•"Structure Panel -> Nuts & Bolts -> Form Options -> Generation Options -> Properties -> Preview Data -> Prepop Data Content"
Below, we give some sample prepop data in XML.
Note: all endpoints and Job Delivery steps do not display forms and therefore do not require prepop data.
In the following example, we use the 1-Step Review template template's JSON definition and derive the prepop XML manually. There are only 2 form states to prepopulate, as endpoints and Job Task Assign types are handled by TM and do not require forms. (We have not shown Job Task Assign steps in the Workflows topic as they are not relevant. You can find them in the 1-Step Review JSON Definition and the 2-Step Review JSON Definition.)
Prepop XML data:
There is no prepop data for the Start step. Transaction Manager only prepoluates the form at all the subsequent steps of the collaboration job.
JSON Definition Fragment:
{
"name": "Application Review",
"type": "",
"actions": [
{
"name": "Assign Review",
"type": "Job Task Assign",
"properties": [
{ "name": "Task Assign Group", "value": "Quote Reviewers" },
{ "name": "Task Form Code", "value": "insurance-review" },
{ "name": "Task Message", "value": "Please review the ${submission.formName} by ${formDataMap.firstName} ${formDataMap.lastName}." },
{ "name": "Task Review Previous Step", "value": "true" },
{ "name": "Task Subject", "value": "Review ${submission.formName} by ${submission.contactEmailAddress}." }
]
},
{
"name": "Review Wait",
"type": "Job Task Wait"
}
],
"routes": [
{ "name": "Approve", "nextStep": "Application Delivery" },
{ "name": "Reject", "nextStep": "Application Rejected" }
]
},
Prepop XML Data:
<AvokaSmartForm>
<SFMData>
<SystemProfile>
<Job>
<ReferenceNumber>whatever-10</ReferenceNumber>
<StepName>Application Review</StepName>
<AvailableRoutes>Approve|Reject</AvailableRoutes>
</Job>
</SystemProfile>
</SFMData>
</AvokaSmartForm>
In the following example, we use the Standard 2-Tier Work flow service template's JSON definition and derive the prepop XML manually. There are only 4 form states. Fortunately there is only 1 set of prepop data: for the "Initial Review" step.
Prepop XML data:
There is no prepop data for the Start step. Transaction Manager only prepoluates the form at all the subsequent steps of the collaboration job.
JSON definition fragment:
{
"name": "Initial Review",
"type": "",
"expiryRule": "+1d",
"actions": [
{
"name": "Create Task",
"type": "Job Task Assign",
"properties": [
{ "name": "Process Message Send Email", "value": "true" },
{ "name": "Process Message Submission Step", "value": "Start" },
{ "name": "Process Message Text", "value": "Your ${submission.formName} application is at the Initial Review Step" },
{ "name": "Task Assign Group", "value": "##GET_FORM_PROPERTY('Review Group Initial')" },
{ "name": "Task Message", "value": "Please perform the initial review of the ${submission.formName} from ${formDataMap.firstName} ${formDataMap.lastName}." },
{ "name": "Task Review Previous Step", "value": "true" },
{ "name": "Task Subject", "value": "Initial review of ${submission.formName} from ${formDataMap.firstName} ${formDataMap.lastName}" }
]
},
{
"name": "Handle Submission",
"type": "Job Task Wait",
"properties": [
{ "name": "Conditional Route Name", "value": "#if ( $formDataMap.routeName == 'Approve' && $formDataMap.loanAmount >= 20000 ) Exceeds Threshold #end" }
]
}
],
"routes": [
{ "name": "Decline", "nextStep": "Applicant Update" },
{ "name": "Approve", "nextStep": "Approved Complete" },
{ "name": "Exceeds Threshold", "nextStep": "Additional Review", "display": "false" },
{ "name": "Expiry", "nextStep": "Additional Review", "display": "false" },
{ "name": "Terminate", "nextStep": "Terminated Initial" }
]
},
Prepop XML data:
<AvokaSmartForm>
<SFMData>
<SystemProfile>
<Job>
<ReferenceNumber>whatever-20</ReferenceNumber>
<StepName>Initial Review</StepName>
<AvailableRoutes>Decline|Approve|Terminate</AvailableRoutes>
</Job>
</SystemProfile>
</SFMData>
</AvokaSmartForm>
Notes: if the Initial Reviewer approves the application, it will go to Additional Review if:
▪the amount exceeds the threshold
▪if the Initial Review expires or exceeds some timeout
These two appear in the "routes" in the JSON, but they both have a "display" attribute with the value of "false". In other words, these routes are not presented on the form as choices. This means that they are not to be included in the "AvailableRoutes" tag of the prepop XML. That is because the decision to follow these two routes is not in the hands of the operator. TM makes the decision to route to Additional Review. Initial Reviewers only get to choose "Decline", "Approve" or "Terminate".
JSON definition fragment:
{
"name": "Additional Review",
"type": "",
"actions": [
{
"name": "Create Task",
"type": "Job Task Assign"
},
{
"name": "Handle Submission",
"type": "Job Task Wait"
}
],
"routes": [
{ "name": "Decline", "nextStep": "Applicant Update" },
{ "name": "Default", "nextStep": "Approved Complete" },
{ "name": "Terminate", "nextStep": "Terminated Additional" }
],
.........
},
Prepop XML data:
<AvokaSmartForm>
<SFMData>
<SystemProfile>
<Job>
<ReferenceNumber>whatever-20</ReferenceNumber>
<StepName>Additional Review</StepName>
<AvailableRoutes>Decline|Default|Terminate</AvailableRoutes>
</Job>
</SystemProfile>
</SFMData>
</AvokaSmartForm>
JSON definition fragment:
{
"name": "Applicant Update",
"type": "",
"expiryRule": "+5d",
"actions": [
{
"name": "Create Task",
"type": "Job Task Assign",
"properties": [
{ "name": "Process Message Submission", "value": "##GET_START_SUBMISSION()" },
{ "name": "Process Message Text", "value": "Your ${submission.formName} application has been declined it, it requires you to provide additional updates." },
{ "name": "Task Assign User", "value": "##GET_START_USER()" },
{ "name": "Task Message", "value": "Please revise your ${submission.formName} as it was declined because: ${formDataMap.reasonForDecision}." },
{ "name": "Task Review Previous Step", "value": "true" },
{ "name": "Task Subject", "value": "Please revise your ${submission.formName}." }
]
},
{
"name": "Handle Submission",
"type": "Job Task Wait"
}
],
"routes": [
{ "name": "Update", "nextStep": "##PREVIOUS_STEP()" },
{ "name": "Expiry", "nextStep": "Terminated Applicant", "display": "false" },
{ "name": "Terminate", "nextStep": "Terminated Applicant" }
]
},
Prepop XML data:
<AvokaSmartForm>
<SFMData>
<SystemProfile>
<Job>
<ReferenceNumber>whatever-20</ReferenceNumber>
<StepName>Applicant Update</StepName>
<AvailableRoutes>Update|Terminate</AvailableRoutes>
</Job>
</SystemProfile>
</SFMData>
</AvokaSmartForm>
Now that we have the prepopulation data to simulate all the collaboration steps, we can begin to add collaboration to our forms and be able to test aspects of the form's behavior, prior to doing end-to-end testing.
