cancel
Showing results for 
Search instead for 
Did you mean: 

When is the Archival API license needed?

Clayton_Blohm
Star Contributor
Star Contributor

This question seems to periodically resurface in discussions of API licensing and I cannot seem to find a useful answer.

The "Archival API" license has been around for quite some time, but does not seem necessary after the introduction of the Unity Integration Toolkit license.

Are there instances where the Archival API license is appropriate, or are there specific use cases that require it?

The only one I can come up with myself I am not certain of... external submission of unity forms... the Archival API apparently triggers the automatic release of a concurrent license, but this may occur even without it. (I can't tell for certain)

Thanks,

- Clay

1 ACCEPTED ANSWER

Zhengxin_Guo
Confirmed Champ
Confirmed Champ

Hi! Clay,

In order to logon to Onbase via Unity API, you have to have standard client licenses Concurrent Client or Named User licenses, or Query Meter license.  In order to use Unity API, you also have to have either functional licenses Unity Integration Toolkit or Unity Automation API enabled based on different purpose. In the Onbase SDK, it states both Unity Integration and Automation licenses include access to the archival of new documents into Onbase. That means "the Archival API license does not need to be purchased separately in order to archive through the Unity API". So, I would assume Archival API license is also a functional license which allows you to archive new document to Onbase. It should have nothing to do with Concurrent license. Archival API license is needed Only if using the OnBase Client or DMCoreX API.

Hope this helps. Thanks!

Jason

View answer in original post

4 REPLIES 4

Zhengxin_Guo
Confirmed Champ
Confirmed Champ

Hi! Clay,

In order to logon to Onbase via Unity API, you have to have standard client licenses Concurrent Client or Named User licenses, or Query Meter license.  In order to use Unity API, you also have to have either functional licenses Unity Integration Toolkit or Unity Automation API enabled based on different purpose. In the Onbase SDK, it states both Unity Integration and Automation licenses include access to the archival of new documents into Onbase. That means "the Archival API license does not need to be purchased separately in order to archive through the Unity API". So, I would assume Archival API license is also a functional license which allows you to archive new document to Onbase. It should have nothing to do with Concurrent license. Archival API license is needed Only if using the OnBase Client or DMCoreX API.

Hope this helps. Thanks!

Jason

That was my assumption. Thanks for the confirmation.

The Unity Forms MRG for OnBase 17 states in the Shared Forms section that:

 

"A Unity Form that is shared via a URL using the Share Form option will consume a license when the form is submitted into the OnBase repository. Concurrent Client license consumption will be held after the form is submitted until the normal time out occurs. When licensed for the Archival API server license, the concurrent license is released immediately without having to wait the session timeout required with a standard concurrent license… Note: Core Query API licenses are only available for external users".

 

So, if I need to expose a Shared Form to hundreds of internal employees (sales promoters in my case), seems that I can't use Query API. Instead, I need to buy a lot of concurrent licenses, enable SSO and buy an Archival API in order to release ASAP the licenses. Am I right?

 

During some concurrency tests (at this time only have named & concurrent licenses as Query nor Archival licenses have been purchased), using a fixed named user for authentication in the Shared Form, OnBase is allowing up to two simultaneous submits (how so?).

 

BTW, Integration Guide is not clear regarding licensing schema for any of the POP options.

Benjamin_Peter1
Confirmed Champ
Confirmed Champ

What about the specific use cases for Unity Form submissions and LoginFormProc?

i.e. If you don't want to use Query Blocks, or a Concurrent Client, or even a blanket 'Named User' (near instantaneous release)?  Meaning, in the rare cases of potentially thousands of form submissions per minute?