Altair Sao：跨多个供应商的合并报告，以启用右尺寸许可清单

A common scenario encountered in many companies is the existence of many different license files from one software supplier with the same software features used by different vendor daemons. For example, a company could acquire software licenses from one supplier for CAD and CAE at different times and at different locations. Software features in all these license files could be identical. In cases like these, it becomes extremely difficult to measure真的usageof such software features within the company. Read the section titled使用供应商和功能池的供应商合并below to see how a company can significantly reduce licenses thanks to the tools SAO provides.

Example: Feature Pool

一些软件供应商根据获取这些功能的时间在同一许可证文件中使用相同功能的功能名称变体。因此，像MD这样的CAD功能可以显示为MD_XXX，MD_YYY，MD_ZZZ等。大多数软件使用跟踪系统都将为每个功能提供使用信息，而在实际软件中，所有这些功能都应仅报告为一个功能。

Altair Sao通过定义一个名为MD的功能池，该功能池池，该功能池池，该功能池池，该功能池池，该功能池，MD_XXX，MD_YYY，MD_ZZZ等，因此，确定的总可用性是每个功能的许可证计数的总和。同样，也可以为不同许可证文件中存在的同一功能创建功能池。Altair Sao提供了一种管理工具，可以轻松定义这些功能池。

Example: Vendor Pool

Altair SAO provides out-of-the-box functionality to define vendor pools by assigning different vendor daemons to a pool. All of these vendor daemons serve licenses using their own license file. Vendor Pooling is very useful when a company has multiple vendor daemons provided by the same supplier. When different vendors are pooled together for reporting, and feature pools are defined for identical features existing in different license files, the license count for each software feature from each vendor is added up to get a total license count. Altair SAO provides an administration tool to define Vendor Pools.

It might so happen, based on how these vendor daemons are configured to provide licenses, that there could be denials even without exceeding the total available license count in the vendor pool for the feature, because one of the vendor daemons could have run out of licenses for a software feature but would obviously not be aware of the total license count for the feature across all vendor daemons.

使用供应商和功能池的供应商合并

当有多个使用自己的许可证文件提供许可的供应商守护程序时，公司通常会尝试将其合并为一个或两个供应商守护程序。为了做到这一点，需要有一种方法来检查所有这些供应商守护程序的软件使用情况，以评估许可证文件中每个软件功能的“ true Peak”使用。

让我们检查下面提供的简单示例：

该图表显示了由2个供应商守护程序提供的特定软件功能的峰值软件使用，其中一项是密歇根州（东部时区）的峰值软件，而加利福尼亚州（太平洋时区）则提供了一项。时间轴显示在GMT中。密歇根州供应商守护程序的许可证文件具有28个功能的许可证，而加利福尼亚供应商守护程序的许可证文件具有16个同一功能的许可证。如果公司使用这两个供应商守护程序的总许可证巩固这两个供应商守护程序，则新的许可证文件可能具有28+16 = 44个许可证。

但是，经过仔细检查，尤其是由于时区的差异，密歇根州的用户最常在加利福尼亚州的用户前3小时开始使用该软件。查看GMT中出现的合并峰值使用情况，很明显，实际上，实际的实际峰值使用不超过36！如果实际上该公司将这两个许可证和供应商守护程序合并为一个，那么该软件功能的总许可证总数为36，这足以比该公司今天支出的总许可证少8个。

使用这2个供应商配置供应商池，并使用Altair Sao配置此软件功能的功能池，可以为该软件报告“ True Peaks”，从而节省潜在的节省。

使用供应商和功能池处理假拒绝

In some cases, end users can have software installed on their desktop pointing to a number of vendor daemons in a certain order. When a license is requested, the license path or pointer attempts to check out a license from the first vendor daemon in the list, and if there are no licenses available, it hops to the second vendor daemon till finally either the software is either able to checkout a license from a vendor daemon that has licenses, or a denial is reported. While hopping through these different vendor daemons, a number of denials are generated in a short time span. If the user ultimately gets a successful license checkout from one of the vendor daemons, the earlier denials should not be reported as denials at all because there will be a successful license checkout within a minute or two after getting multiple denials from the vendor daemons appearing initially in the list. Defining a Vendor Pool for these different vendor daemons, and a Feature Pool for all identical features available in individual license files, provides for a way to filter out ‘false denials’.

请继续关注下一篇有关Altair Sao的许可模拟器的SAO博客文章，该文章将启用“假设”分析！