RE: Unity Script to Workview

[Aaron_Fryzek]

Megan / Hyland Team,

Can you expand exactly on what is needed for a specific scenario?

• Public Users - unknown how many specific users, but scenario has 1200 applications(cases) submitted a year - public users may check in at frequent intervals - there will be some peak periods with higher number of users at once (lets estimate 100 users)
• Connection with Unity API
• Request to Store and Retrieve Data stored in Workview Objects

From reviewing with our API team and the documentation, here is what I am finding as required/recommended:

• Unity Integration ToolKit - provides access to Workview functionality
• Query Meter Licensing - provides client connection access on a "per-query an hour" type of rate - recommended approach vs concurrent clients

Where I get stuck is in the documentation for "Unity WorkView Licensing" which states that an appropriate Client WorkView license will be required to make use of the Unity Workview API in an integration mode(i.e., from outside of the WorkView Client Software) vs the comment that states the Unity Integration Toolkit provides full access to the Unity API functionality.

Does Unity Integration Toolkit provide full Workview functionality or is that limited based on the need to also have a workview license?  How does that compare to utilizing workflow actions/rules?

Is there a recommended licensing approach for building public integrations to publicly expose retrieving and updating workview data elements? (Certainly we also have a large number of internal users who will utilizing Workview once the data is submitted)

Thanks

-Aaron

[Adam_Ryman]

Good Afternoon Aaron,

Based on your description of the current architecture, I would agree as it appears that Unity Integration Toolkit, paired with Query Metering would be ideal.

The Unity Integration Toolkit gives full access to all the Unity namespaces including Workflow as well as Workview. Please note this license is for use external to the client.

When you perform an action in the API utilizing the Workview namespace, a Workview concurrent/name license will be consumed in addition to the connection made via concurrent/query metering. Therefore, while the Unity Integration Toolkit does include the functionality to perform Workview related functionality, it is still dependent that a Workview license is available to the user executing the API code for Workview API functionality. This would be on par with Workflow as well.

To touch on your last question involving recommended licensing, I am not exactly sure I follow. Can you please further elaborate on this question?

Thanks,

Adam Ryman - Hyland API Analyst

[Aaron_Fryzek]

Adam - thanks for the quick response.  Based on what you have identified and I believe others from Hyland have also confirmed, the requirements to get data from Workview objects through the API for external users requires the following:

1) Workview License / 2) Unity Integration Toolkit / 3) Query Meter license(or applicable client license)

We are working with a couple of other contacts at Hyland(our sales and SA contacts) to ensure that the value of functionality in a public scenario match the cost associated with the 3 listed components. As our number of public users increases, our potential need of concurrent clients increases as well, and our desire to ensure the public receives the best possible experience can create a high cost entry point to provide the data.

Certainly willing to loop you into our other conversation offline if that makes the most sense.

Thanks again,

Aaron

[Adam_Ryman]

Aaron,

When it comes to determining the appropriate license architecture to implement for your given business process, this would be better handled by your account manager.

If you are trying to determine the appropriate number of licenses needed utilizing the query metering license schema, we do have a couple ways of doing so that I can provide. Is this what you are trying to determine?

Thanks,

Adam Ryman - Hyland API Analyst