APIs represent real backend APIs (Application Programming Interfaces). An API is also known as a service, which offers a HTTP, REST or SOAP interface that can be invoked remotely by a client.

Scheer PAS API Management provides a way to turn unmanaged (raw) back-end APIs into managed APIs by attaching policies to them. Any policies configured on an API will be applied at runtime, regardless of the client and API contract.

An API has to be fully configured, including policies and implementation (and in case of public APIs including plans) to be published. If the API has been published to the gateway it can be consumed - in case of private APIs by clients.

Refer to API Management Guide > APIs for more details.

The API Developer Portal allows you to grant customer developers access to your APIs. In the Developer Portal, developers can sign up for APIs, access them, and try out APIs that you have enabled for them. The portal is designed to keep the discovery and use of APIs simple for the target group. 

Refer to API Management Guide > Developer Portal for more details.

A policy is a rule or a set of rules API Management uses to manage access to your APIs. Policies are applied to all API requests and represent a unit of work applied at runtime to the request by API Management.

Policies are applied through a policy chain: when a request to an API is made, API Management creates a chain of policies to be applied to that request. The policy chain is applied to the request in a fixed order: Client policies are applied first, then policies added to plans, and finally policies added to the API itself.

Refer to API Management Guide > Policies for more details.

The visibility concept of API Management defines which user groups can find the APIs in the Developer Portal. The visibility resides on top of the permission system as another security layer. Visibilities are applicable to public APIs and plans for private APIs. Three different visibilities are available: Organization members (default), API Management users, and API Developer Portal users.

Refer to API Management Guide > The Concepts of API Management for more details.

Data mapping is a very common task in the integration business: It is the process of connecting a data field from one source to a data field in another source. The Designer comes with a mapping editor that allows you to define attribute mappings directly in a mapping diagram by drawing relations between the properties of the involved classes.

Mapping diagrams are automatically created if you create a mapping operation on a class. The mapping diagram is based on the data model contained in the Implementation folder. It defines mappings between the data structures defined in this data model. You cannot change the data model in the mapping diagram, all attributes are read-only.

If you want to learn more about data mapping, refer to the chapters Modeling Data Mapping and Mapping Data Structures in the Designer guide.

Processes are based on data that is going in, is processed, and coming out. However, the application developer must determine which data can be accessed in which process step. Therefore, the execution diagram contains different sections:

• Message: Section  Message  is shown for all BPMN elements that need to process an incoming message.  As per default, the incoming message has type any . To gain access to the data used in your process, you have to apply the correct type from a customized library.
• Persisted: Variables created in section  Persisted  are usable in all executions of the BPMN model. They are "persisted" during the execution of the entire process.
• Local: Variables created in section  Local  are only available for use within the current execution. They are discarded when switching to the next process step.

Data that you want to be able to access throughout the process, you need to keep - this is the meaning of "persisting data".

If you want to learn more about how to persist data in the Designer, refer to Designer Guide > Persisting Data.