Rules and Standards

CAA Authorized APIs

Moving Authorized APIs and Authorized API usage and control

Abstract

CAA Authorized APIs are now located in the PublicInterfaces directory of each framework. In addition, the former AuthorizedAPI.txt text file is now supplied encrypted as AuthorizedAPI.script. This article explains these changes and gives you tips an recommendations to get your applications going on building on top of these Authorized APIs.

CAA Authorized API Location Changes in Brief
- Location of CAA Authorized APIs
- The AuthorizedAPI File in \tools\config of the RADE Installation Directory

CAA Authorized API Location Changes in Brief

Starting from CAA V5R12, the Authorized APIs progressively move to the PublicInterfaces directory of the frameworks.

Location of CAA Authorized APIs

Before V5R12	During V5R12 Lifetime

Up to V5R11, the CAA Authorized APIs and the DS Internal Resources of a framework are mainly located in the framework's ProtectedInterfaces directory. The Authorized APIs can be differentiated from the DS Internal Resources by opening the files to locate the CAA exposition tags or consulting the CAA Encyclopedia.	Starting with V5R12, the CAA Authorized APIs are progressively moved to the PublicInterfaces directory, while the DS Internal Resources remain in the ProtectedInterfaces directory.

[Top]

The AuthorizedAPI File in \tools\config of the RADE Installation Directory

Before V5R12	During V5R12 Lifetime

Up to V5R11, the AuthorizedAPI.txt file is not secured. Only with Dassault Systèmes support, this file could be modified to enable a DS Internal Resource to be used in a CAA application.	Starting with V5R12, the AuthorizedAPI.txt file is supplied encrypted and changed to AuthorizedAPI.script. It cannot be modified.

To help developers use only Authorized APIs, mkmk checks that CAA applications only use Authorized APIs and issues an error if a DS Internal Resource is used. But this is a corrective check, not a predictive one and forces CAA developers to review their coding and possibly their design when the application is ready to be built.

Using a DS Internal Resource is stricly prohibited. For this reason:

DS Internal Resources are NOT documented in the CAA Encyclopedia
DS Internal Resources in the PublicInterfaces directory are either tagged
- @nodoc
- @CAA2Required: in this case they are referenced indirectly (no explicit include to be done in CAA application) and must not be used directly
DS Internal Resources in the ProtectedInterfaces folder are not tagged.

You can refer to the CAA Encyclopedia to know about the CAA V5 Authorized API Usage, Deprecation, and Stability [2].

[Top]

References

[1]	CAA Internet Site
[2]	CAA V5 Authorized API Exposition, Usage, Deprecation, and Stability

[Top]

History

Version: 1 [Jul 2003]	Document created
[Top]