Licensing for automation sessions

In automation sessions, multiple threads of the calling application may overlap. For example, a web application can call the Mongoose IDOWebService to query data to present. When making a call to the IDO Web Service, the web application supplies a specific user ID, password, and configuration. The web application can have multiple threads executing simultaneously, so it requires multiple concurrent Mongoose sessions.

Multi-session users are designed for use with automation sessions. They are defined in your license document and are created when the license document is applied.

However, any user can make overlapping web service requests and still only consume one IDO license token, if the IDO Custom User session type is used. This session type is optionally available to sessions that are created during Mongoose REST, WebService, and IntegrationService calls.

Automation sessions can be established using the technologies and tools listed in this topic. Each of these options exposes the same underlying IDO Request interface, as described in the document Integrating IDOs with External Applications. The licensing implications of these options vary, as described in this list:

  • SOAP WebService - These calls are synchronous, consuming a license token during the processing.
  • COM - These calls are synchronous, consuming a license token during the processing.
  • XML - Mongoose utility/web servers provide both synchronous and asynchronous URLs. The calling process must format an IDORequest XML document, and then decide whether to use the synchronous route or asynchronous route:
    • For the synchronous route, an automation session is established for the user specified in the XML, consuming a license that is assigned to that user. (Often this user is assigned a MGCoreAutomation license, because MGCoreAutomation is the only license module that contains all the MongooseIDOs plus customer-created ones.) The synchronous route allows the calling application to receive the results of the request.
    • For the asynchronous route, although security is checked for the user specified in the XML, no licensing consumption occurs. The processing is performed by the framework service ReplQListener. XMLs processed this way require a valid user, but that user does not need to take licensing into account, only security.