Multiple external data sources

[Rob_Dale]

For one of our Doc Comp letters the requirement is to have multiple external data sources, where each subsequent data source uses placeholders retrieved from the first data source.  

For example, you enter a contract number, and receive a list of clients attached to that policy.  You then select a client, and return additional information, and so on.

The only way I can come up with is dropping this into a workflow, using HTML prompts to ask the data, then use unity scripts to make the next call, and fill in data on a new HTML form, ultimately triggering Doc comp.

Is this the best way to accomplish this?  Is there something else I should be trying?

Thank you.

[Alex_French · Accepted solution]

Rob,

One option might be to use a client side script (probably an IClientWorkflowScript, or maybe just an IClientScript).

These are Unity scripts that execute client-side, and are usable only in the Unity client.

Because they execute client-side, they have access to everything local- most importantly, you can do something like call your own Windows Forms GUI.

That GUI (which you would have to code from scratch) would give your user the full set of choices in one interface, with the experience being as slick as you want to make it.

Because the script executes client-side, it doesn't have access to server-side ODBC connections- if your data isn't already available through a web service, you might need to create a web service to get to it, that can be called from your Windows Forms GUI.  Also any writing to the Diagnostics Console will happen on the client machine- so during development you can run Diagnostics Console on your own machine, but you probably won't have any comparable option for real end users if you ever need it.

------

Another option might be to write an HTML form that uses client-side Javascript to create an interface similar to what I described above.  Again, it would interact with source data through a web service of some sort.

We write very complicated E-Forms with a huge amount of client-side javascript and web service interaction- I think the same techniques could be used in an input form called from "Display HTML Form" (non-autogenerated), but we haven't done it.

This approach could give you all the same options as the client-side script, but wouldn't rely on the Unity client, and would use a different skill set (client-side javascript vs. C#).  If I was okay with being tied to the Unity client, I think the client-side Unity script is a less risky approach.  Any client-side code in an E-Form or HTML User Form is executing inside an environment that isn't entirely like a normal browser, and Hyland could change some of those details at any time.

----

Another option, that I just noticed while reviewing the "Display HTML Form" WF action, might be to use "Display Unity Form For Input", and then do the work in the Unity Form.  I haven't worked with scripts inside Unity Forms, so I'm not sure whether that approach would simplify things by using an off-the-shelf component, or complicate things by tying you to the Unity Form when it would be easier to just write your own Windows Forms GUI.

----

For completeness, I'll bet there's a way you could use WorkView, and External Classes (SQL or Unity Script based) to create an interface to accomplish the same thing.  You would probably create and display a WorkView object just to act as the GUI.  If your external data could work as a SQL External Class, this might actually be the least-code option- but it still seems pretty roundabout.

The techniques discussed in this Community post would probably be relevant to making it work:

www.onbase.com/.../how-to-constrain-an-embedded-filter-relationship-attribute-lookup-by-another-rela...

----

I hope one of those helps!

If it were me, I haven't talked myself out of the client-side Unity script as the cleanest approach so far.  It means a lot of code to write, but it doesn't get too many other "moving pieces" involved (though you might have to write a web service to get to something you could just access via ODBC in a client-side script).

Alex French

Dartmouth College