Integration and REST/SOAP Services
This domain tests how the app talks to other systems: consumed REST services, published REST services, SOAP web services, import and export mappings, authentication, and error handling on outbound calls.
Consumed REST
A consumed REST service document holds the base URL and a list of operations: HTTP method, path, query parameters, headers, request body, response handling, and authentication (none, basic with credentials, or custom). The microflow activity Call REST invokes the operation and returns the response, either as a string or mapped into entities by an import mapping.
Mappings
Import mappings turn a JSON or XML structure into objects; export mappings turn an object into JSON or XML. To build either, you first import a sample message or schema so Studio Pro knows the structure - you cannot hand-write field mappings without it.
Published REST
You publish a resource with a URI and operations; each operation is handled by a microflow whose parameters come from the path, query string, or body, and which returns the entity or mapping that becomes the response. Authentication is configured on the published service.
Worked example
Requirement: look up a city's weather. Reasoning: import a sample JSON response to create the structure, build an import mapping to a non-persistent entity, define a GET operation with a city query parameter, call it from a microflow, and pass the result to a page. Non-persistent is correct because the payload is transient; committing it would write worthless rows. Handle non-2xx responses with an error handler so a failed API call does not produce a blank page.
Traps
- API keys hard-coded in constants end up visible in the model; use environment-specific constant values.
- A published service returns what its handler microflow returns - returning nothing yields an empty response.
- SOAP uses the same mapping idea but starts from a WSDL or XML schema.