eiigt.over-blog.com/
4 Décembre 2020
This topic describes the main components of the Genesys licensing system, which is implemented via License Server Manager, and explains how this system works. Information in this topic is divided between these subtopics:
The FLEXlm/FlexNet Publisher License Server is a daemon process that runs continuously in the background, tracking how many instances of Genesys licenses are utilized on a network.
This document is available through the Product and Licensing Center, or in the Documentation area in Customer Community. (An archive copy for your future reference is also available through the title page of online help after the product is installed.) To obtain and activate a FlexNet Manager Suite license file. The FlexNet Connect C SDK Application Programming Interface reference describes the modules and functions of the C libraries that comprise the FlexNet Connect C SDK. This reference is not available as a PDF. Rather it is delivered as HTML-based online documentation archive. FlexNet Connect C SDK Getting Started Guide. The FlexNet Connect C SDK.
The License Server consists of a License Server Manager and the Genesys vendor daemon.
At startup, all licensed Genesys FlexEnabled applications establish a client connection to License Server, providing a computer host ID or IP address, along with various information about the application. If License Server finds a valid license for the application, it permits the application to start and run properly.
The license server responds to a FlexEnabled application's checkout request for a license if licenses are available. The license server counts the number of licenses that are in use and the number of licenses that are still available. The server can also provide reports on which licenses are being used and by which users.
While licensed applications run, the License Server and FlexEnabled application send polling messages to each other at certain intervals. The license server or FlexEnabled application can therefore know if the application or license server has terminated abnormally. If the application terminates because of a process or runtime environment failure, the license server records the information about the license(s) no longer being in use.
Genesys License Manager incorporates the FLEXlm 9.5 license manager, and the FLEXlm FlexNet Publisher 11.7 and 11.9 license managers inherited and developed by Flexera. FlexNet Publisher is the successor product name for FLEXlm, and is highly backward compatible with earlier FLEXlm versions. For the purpose of simplicity, these are referred to as 'License Manager', or 'Flex', generically, whether FLEXlm or FlexNet Publisher.
Beginning with Genesys Release 8.1, a new version of License Manager is required for use of Genesys products with certain, newer, 64-bit operating systems, as shown below.
| Operating System | Bit Mode | License Manager Version | Management Framework Version | Flex lmutil Version |
|---|---|---|---|---|
| 64-bit native | FlexNet Publisher 11.9 | Management Framework 8.1+ | lmutil 11.9+ |
| Windows Server 2008 | 32-bit |
|
|
|
| All other Genesys-supported OS versions not listed above | 32-bit |
or
or
|
|
|
For mixed environments and incremental migrations, FlexNet Publisher 11.x is fully backward-compatible with existing 7.x and 8.0 applications. For example: If you are running CIM Platform 7.x or 8.0 and other 7.x or 8.0 applications, on Windows Server 2008 64-bit native, and wish to migrate to Release 8.1 while continuing to run your other existing Release 7.x or 8.0 Genesys 32-bit applications in parallel, you may do this by upgrading to FlexNet Publisher 11.9. You may migrate the Release 7.x or 8.0 applications at a later date.
Genesys provides vendors' documentation: License Administration Guide - FlexNet Publisher Licensing Toolkit 11.9, in the License Manager installation package.
The License Manager architecture contains these components (see Licensing Process):
The LM daemon (lmgrd ) executes two major tasks. First, it initiates commerce with the client applications, passing the connection on to the appropriate vendor daemon. Second, it starts and restarts the vendor daemons. Genesys maintains the Flex capability of running multiple redundant License Manager daemons on three server nodes, so that licenses are available if any two of the three nodes are running (see Three-Server Redundant Configuration for details).
Licenses are administered by running a process called the vendor daemon, which records how many licenses are checked out and who has them. If the vendor daemon terminates for any reason, all users lose their licenses (this does not mean the applications suddenly stop running). Users normally repossess their licenses automatically when lmgrd restarts the vendor daemon, although they may exit if the vendor daemon remains unavailable. The Genesys daemon is called genesys.d for and genesys.d.exe for Windows.
Client programs communicate with the Genesys daemon through TCP/IP network communications. Genesys applications and the daemon processes (the license server) can run on separate hosts on a single network (local area) or across a wide-area network of any size.
Licensing data is contained in a text file that Genesys creates, but which you edit and install. Genesys recommends saving this file under the name license.dat; however, this is not mandatory. The editing procedure is described in Editing the License Data File.
The file contains information about the license server host name, license server host ID, license server port, vendor daemons, and one or more lines of data, called a FEATURE line, for each licensed product. You can edit a license data file by adding FEATURE lines for new product licensing, even if the products belong to different vendors.
As long as License Manager can access the license file, the file can reside on a computer other than the one running License Manager.
At launch, Genesys server applications that require technical licenses connect to the license server and request a license. For this connection to occur, you must inform applications about the license server location. Specify the license server location by using a command-line parameter or the license-file option you configure for an application.
For detailed information, see Installing License Manager.
When you launch a Genesys application that requires a license:
If a license is available, the license server returns licensegranted to the client and the application starts operating.
If no licenses are available, the license server sends licensedenied; the application generates an appropriate log message (log event #00-07100LicensingViolation ) and exits. Estatistica pro 1 1 2 straightener.
The following sections document any deviations in application behavior from the standard license checkout process.
Genesys Desktop Server checks out a user-specific license (either Genesys Agent Desktop or Genesys Supervisor Desktop) when a user (either an agent or a supervisor) submits login parameters to start a web session. If a license is not available, the desktop window does not open. The server closes the user's web session and checks in the license when:
Genesys Integration Server checks out a license of the connection type when a client tries to open a connection. If a license is not available, the connection is denied. The server checks in the license when the connection is closed, either at a client's request or because of the timeout.
At startup, OCS checks out as many licenses as are specified by its num-of-licenses configuration option (providing this amount does not exceed the amount specified in the license file). When the number of agents logged into Queues associated with one or more loaded Campaign Groups reaches the number of licenses checked out, OCS generates the Licensing Violation message: reason for the violation is that the feature usage level has been exceeded for every new agent that has logged into the campaign-related Queue. When an agent currently associated with a loaded Campaign Group logs out of the Queue or OCS unloads the Campaign Group, OCS reuses these freed licenses for new agents (and, if the licensing violation has been reported, removes it).
Because OCS controls the licenses while the switch (through the ACD Queue configuration) or URS (through routing strategies) controls the distribution of an outbound call, the agent who is denied the license may receive the call. As a result,
When T-Server receives licensedenied at startup because it has requested more licenses than are currently available, it checks out the maximum number of licenses that are available. If a single license is not available, T-Server generates the LicensingViolation message and exits.
To ensure that T-Server does not initially request too many licenses, set the corresponding T-Server configuration options to values less than the total number of T-Server-related licenses you have purchased. Pay particular attention to these option settings when using more than one T-Server.
UCS licenses are checked out at startup. The maximum number of licenses that can be checked out is specified in the configuration.
Available licenses are decreased upon receiving a callback request or when a license has been blocked. The decrease is incremented 60 minutes after the callback submission or the license block.
For further information, see 'Request for Service Availability Extension' section in the corresponding version of Voice Callback Deployment Guide, and the 'Client-Server Protocol Extension' section in the corresponding version of Voice Callback Reference Manual.
UCS produces a GCTI_LICENSE_FAIL licensing-violation log message with violation type in the following situation:
See the corresponding version of Voice Callback Reference Manual for details on how to configure Autodial on CDNs.
At startup, URS checks out all available licenses. When a logged-in agent appears as a valid target for a call for the first time, URS allocates one of the checked-out licenses to the agent. When the number of logged-in agents that at least once appeared as valid targets reaches the number of licenses checked out, URS generates the LicensingViolation message for every new logged-in agent. An allocated license is freed for URS to reuse when:
In the first two cases, URS may generate a LicensingRestored message.
Take this URS behavior and the fact that agents cannot manually give up licenses into account when determining the number of required licenses. This recommendation especially applies to sites that have many shift changes where new agents log in while the previously working agents have not yet logged out.
For each license FEATURE name there is an Interaction Server configuration option with the same name in thelicense section. The value of each such option is a number specifying the number of licenses of that type that Interaction Server checks out. Interaction Server checks out the configured number of licenses of each type at startup. It also reacts to any value changes of the options in thelicense section.
If the number of licenses in use goes above the configured number of licenses (as a result of logging in agents), Interaction Server forces logout of some agents so that the number of licenses in use is equal to the configured number.
Although a Genesys application encountering a problem with licenses at runtime generates a LicensingViolation log message (a log event with ID #00-07100, it does not interrupt its service and it does not drop current interactions. However, the application may cease to process new interactions until the licensing violation is removed. A licensing violation may occur because:
License Failure Scenarios describes how you should determine and react to licensing violation.
/image%2F6176875%2F20210220%2Fob_309245_converting-formulas-to-values-using-ex.jpeg)
/image%2F6176875%2F20210220%2Fob_0f66df_movavi-chiliburner-3-activation-key.jpeg)
/image%2F6176875%2F20210220%2Fob_dcf9d4_igo-primo-gps-software-windows-ce-5-so.jpeg)
/image%2F6176875%2F20210220%2Fob_e67afe_honda-cb-600-hornet-2008-owners-manual.jpeg)