We have a Forms process that kicks off a workflow and the workflow talks back to Forms so the Forms instance can move forward. How does the Workflow instance know which Forms Server to communicate back to?
Hi Blake,
That's configured in the Set Business Process Variables tool.
Thanks,
Michael
Michael, if you have a Workflow that is not setting variable values back to the Forms instance you do not have to use that activity.
If in Forms you tell the Workflow task to wait until the Workflow is finished before proceeding, that information must be held somewhere. I am assuming it is in a database table in the Workflow database, but I don't know where.
Ah yes, I misunderstood your question. You're talking about if it's in the DMZ or internal, which to use. I imagine that it would automatically know which one to communicate to as that is the Forms server that initiated the workflow in the first place. What happens when you try?
No, that's not the question I'm asking. I simply am wanting to know how Workflow keeps track of which Forms server it needs to communicate back with when Forms kicks off the workflow and is waiting for a Workflow instance to finish before proceeding.
While you say it would 'automatically know which one', it must keep that information somewhere so it can reference it. I am wanting to know where.
Hey Blake,
When Forms invokes a Workflow via HTTP POST to the Workflow Web Service, the POST body contains a "formData" block with the fields below. I'm fairly certain it uses the "callbackURL", which I believe Forms sets as the address of the Primary Forms Server configured in /FormsConfig (should always be the true FQDN of the machine running the Forms Routing Service).
"formData":{
"action":"String content",
"approver":"String content",
"bpID":"String content",
"bpInstanceId":"String content",
"callbackURL":"String content",
"comment":"String content",
"formId":"String content",
"formName":"String content",
"formsHost":"String content",
"initiator":{
"Email":"String content",
"DisplayName":"String content",
"Name":"String content",
"SID":"String content"
},
"instanceName":"String content",
"processId":"String content",
"processName":"String content",
"processTimeZone":"String content",
"startDate":"\/Date(928149600000+0000)\/",
"status":"String content",
"stepId":"String content",
"submissionId":"String content",
"submissions":[{
"Action":"String content",
"Comment":"String content",
"FormId":2147483647,
"FormName":"String content",
"StepId":2147483647,
"StepName":"String content",
"SubmissionId":2147483647,
"Submitter":{
"Email":"String content",
"DisplayName":"String content",
"Name":"String content",
"SID":"String content"
},
"TimeStamp":"\/Date(928149600000+0000)\/"
}],
"submitter":{
"Email":"String content",
"DisplayName":"String content",
"Name":"String content",
"SID":"String content"
}
}
Is there a way to edit these?
We have a Forms installation that was moved to a new server. There were Workflow instances that were still waiting to finish and now they are unable to contact the Forms server to report they have completed. We need a way to update a few hundred of these so they point to the new Forms server.
By far the easiest way way to deal with that issue is going to be putting in a DNS CNAME pointing the old Forms server hostname to the new one. There's a small chance of SSL hostname mismatch errors there, so if you encounter those issue a new cert for the new Forms server that has both its current name and the old server's as Subject Alternative Names.
For the (potentially) harder way, I suspect Workflow stores the callback URLs somewhere in the database, and probably in one of the bp_* tables.
My test instance didn't have any entries so I unfortunately couldn't check.
There are SQL queries you can run to search every value in a database for a particular string. You could try running one of those with the old Forms hostname on your Workflow database. If you find the callback values you're looking for, you can then update them directly in the WF database.
We looked in the bp tables and have not been able to find anything regarding the callback. Are you able to confirm information on your end of how we can find that data?
The best answer here would be to use the skip or retry functionality in Forms 10.4.2 on the new Forms server. If you just need the workflows to complete, skip that step on the new Forms server once the workflows are done. If you need callback, retry the in-progress WF task to get it to run again and successfully call back.
There is a secret key that's used between the forms instance and the invoked workflow. This callbackURL is set when the workflow is called, and you cannot control that from Forms. @████████ may know if Workflow has a way to modify that value.
Otherwise (on a pre-Forms 10.4.2 version), you could contact our support team for a script that would set all the in-progress workflows to suspended. Then you could retry them and have them rerun using the new server info.
@████████, I do not believe either of those is an option in this case. We are potentially looking at thousands of instances in Workflow and we may not see the issue arise for months because of how long it takes the Workflow instance to finish. In Forms the instance shows as running, so in order to know which ones have finished Workflows will take a lot of effort and then to have to go into Forms and click Skip will not be an acceptable option for this Client. We really need a way to modify the address Workflow is trying to communicate back to Forms with.