- 21 Nov 2022
-
DarkLight
-
PDF
Introduction - Schemas
- Updated on 21 Nov 2022
-
DarkLight
-
PDF
Defining data to and from an Adapter
Schema is used to define the data that an adapter sends to and receives from the system it is integrating with. It does not define the overall format of the data to be sent or received (see requestDatatype and responseDatatype in action.json). It is only utilized when the request and responseDatatypes are something that can be translated; for example, JSON, XML2JSON, URLENCODE.
Schema files are located within the adapter Endpoint Configuration (adapter-home-dir/entities/each-defined-entity). Multiple schema files can be utilized by an adapter. Every action within the adapter can have a:
- Request schema which defines the data the adapter will send to the other system on the API request.
- Response schema which will define the data that the other system will send to the adapter on the response.
The request and response do not have to be separate schemas; on CRUD operations they will often be the same schema. When building an adapter from OpenAPI, each action within the OpenAPI will have query or body parameters defined. These can be inserted into the schema files.
There is a good reason to define your schema files. Multiple systems often have a different way of defining data fields. Itential Automation Platform (IAP) will have its way and often the other systems will not conform to that. Thus, you need the ability to translate data between them.
Take the following example:
-
If System A defines a device IP address as ip_addr and System B defines it as ipaddress and IAP defines it as ip_address then something needs to map the fields so that when we get a device from System A it takes ip_addr and puts it into ip_address for IAP.
-
Similarly, when IAP wants to add a new device to System B we take ip_address and put it in ipaddress. This translation happens automatically in the adapter libraries based on the information that you put in the schemas.