How AIS endPoint Mappings Work
AIS clients are developed based on the JSON output returned from a specific EnterpriseOne environment. For AIS clients to function properly, the client must receive JSON responses from the AIS Server (server JSON) that match the expected responses in the client. This is referred to as the client contract.
To generate modified JSON output, the system uses an AISEndPoint.xml file deployed to the EnterpriseOne AIS Server. The AISEndPoint.xml file contains ID mappings in endPoint elements. The ID mappings map the fields expected in the AIS client to the fields being sent by the AIS Server for each EnterpriseOne form.
In the AISEndPoint.xml file, the endPoint mapping is organized in a hierarchy that is equal to the hierarchy of an EnterpriseOne application form, which follows this order:
Form inputs for the main form or the parent form.
Any additional forms, which can be the main form or subforms.
Any form data controls, form action controls, or a grid within a form.
Any columns within a grid.
The AIS Server uses an endPoint mapping to transform the IDs used for both the input and output of a form service request. For input, the requested form IDs and all the IDs used in any grid or form action are replaced with values the server is expecting. For output, all of the IDs within the JSON response for the form are replaced with values expected by the AIS client. Hence the "server" and "client" attributes in the mapping.
Transformations occur only when the application and form listed in the endPoint "module" parameter in the endPoint mapping match the application and form ID requested in the "formName" parameter of the service call. The module might not match the value in the "appOID" parameter. In this case, if the module matches the requested form name, the AIS Server will execute the form defined in the appOID, calling a different form than the form listed in the "formName" parameter.
The following example shows an endPoint mapping in the AISEndPoint.xml file.