An emite IPaaS Integration typically consists of a single primary Action (often executed on a schedule) which is responsible for saving data to the data store (Elastic Search / Open Search) and executed on a schedule / published.
However, a single Action can only interface with a single API endpoint, so how can an emite IPaaS Integration retrieve and consolidate data from multiple API endpoints / multiple data sources?
...
The GetUsers (Primary) Action will retrieve a list of User ID’s and User NamesName's. It will also have a Group Name Mapping which references the second Action GetUserGroup, passing the User ID as a parameter, to retrieve each user’s assigned Group.
...
| Panel |
|---|
| panelIconId | 1f914 |
|---|
| panelIcon | :thinking: |
|---|
| panelIconText | 🤔 |
|---|
| bgColor | #FFFAE6 |
|---|
|
Things to consider: Do your research to ensure that you are using the most optimal API endpoints provided by the 3rd party system. Try and minimise the amount of API endpoints you need to query, in order to meet your specific requirement(s). Only Actions within the same Integration can be referenced, however multiple Actions can talk to multiple data sources within the one Integration. Make use of the eMite IPaaS Action caching feature (see emite IPaaS User InterfaceIntegration Cache) if data is expected to change infrequently. In the GetUserGroup example above, you could save the data to the Integration’s cache, so subsequent Action executions don't waste valuable API calls (retrieving the same data) and instead the Integration’s cache is leveraged for the required Group Name. Most 3rd Party systems require you to authenticate with a separate API endpoint, before you can retrieve data from any other API’s, so referencing a seperate authentication Action is common in most emite IPaaS Integrations. Authentication Actions can be referenced directly within Commands > Headers, using the format bearer {{[Action Name].[Alias]}}, i.e.
 |