12-04-2018 10:46 AM
We are attempting to execute a unity form custom action script that populates another section of the form, and is executed via a condition button located within a row of a repeater section. What we are finding is that this data is not accessible when the next script, executed via an ad-hoc task, is run. The form "reloads" when the script is executed and our populated data is no longer present. Additionally, in diagnostics we can look at the values retrieved and they are all coming up blank.
Additionally, when we manually enter data into the form fields we get this same behavior. Unless we submit the form before executing the task, the data entered does not remain after the form gets "reloaded", and the script does not have access to the data.
When updating the form we use a CustomActionFormModifier and execute ApplyChanges once all of our field modifications are done. We take the form instance directly from the args.
Is this expected behavior? Why is the data populated by the IWorkflowScript accessible from a UnityFormCustomActionScript but not vice versa? Why is data entered manually not accessible by an IWorkflowScript until we execute a submit? Is there some action that needs to be run within the script in addition to ApplyChanges? Forcing the users to submit before each script is executed adds a large amount of additional clicks and time to the process, so if there is any way to avoid this we would like to know about it.
12-05-2018 07:12 AM
I'll expand on Adam's comment a bit and add some suggestions:
Workflow scripts are designed to run against the *stored* values for a document. As you're seeing, you can't even run ad hoc tasks against a form with unsaved changes. This is just how ad hoc tasks work in general - Any rules or actions could be run in a task, and it's easy to see how messy that would get if every Workflow action had to allow for saved or unsaved keyword values. In short, your Workflow script can see keywords and form values, but they will not be values that the user is currently changing.
On the other hand, the Unity Form custom action always runs against a form that is currently open for editing. It looks at the values currently in memory. If you looked at the keyword values in the database, they may not reflect the user's current changes. And even more importantly, this might be a brand new form that has not yet been saved as a document in OnBase. If the interface depended on a Document object existing behind the scenes, that would get confusing.
I'm not sure what your business case is, so I don't know what you are trying to do by running both a custom action script and a Workflow script. But here are a few strategies I can suggest:
12-04-2018 11:17 AM
Hi Warren --
Unity Form Custom Action Scripts interact with the Form Instance, not with a document, and only the form field values are visible; conversely, Workflow scripts execute on documents, and the Keyword values are exposed but not form field data. I do not believe the two can work in tandem in the way you've described, unless I'm misunderstanding the process.
Best,
Adam Kuhn, API Analyst
12-05-2018 07:12 AM
I'll expand on Adam's comment a bit and add some suggestions:
Workflow scripts are designed to run against the *stored* values for a document. As you're seeing, you can't even run ad hoc tasks against a form with unsaved changes. This is just how ad hoc tasks work in general - Any rules or actions could be run in a task, and it's easy to see how messy that would get if every Workflow action had to allow for saved or unsaved keyword values. In short, your Workflow script can see keywords and form values, but they will not be values that the user is currently changing.
On the other hand, the Unity Form custom action always runs against a form that is currently open for editing. It looks at the values currently in memory. If you looked at the keyword values in the database, they may not reflect the user's current changes. And even more importantly, this might be a brand new form that has not yet been saved as a document in OnBase. If the interface depended on a Document object existing behind the scenes, that would get confusing.
I'm not sure what your business case is, so I don't know what you are trying to do by running both a custom action script and a Workflow script. But here are a few strategies I can suggest:
12-05-2018 09:02 AM
As always, Nevin has the best advice!
12-06-2018 07:32 AM
Essentially, there are a couple of web services that this form needs to interact with. Data from an OCR'd form comes in and gets correlated versus data retrieved from this web service, and is then either modified or a new object is created. In total there are 6 different webservice calls. Two of these calls involve opening a web page for the user to then interact with. Ideally, we were going to use custom actions to drive the user interaction, but because we have to open an external web page for 2/6 calls we opted to just put everything within the ad-hoc tasks. Even with those ad-hoc tasks we are still using some unity form custom action scripts to move data around within the form, which i guess is whats causing our issues.
Is there a way for us to display a web page to a user from a custom action script (or some other unity form tool)? If that is possible, we can just refactor our solution to use custom actions instead of this combination of scripts like we have now.
Find what you came for
We want to make your experience in Hyland Connect as valuable as possible, so we put together some helpful links.