Integrations currently only allow for a single endpoint to be configured in isolation - this is not good as we need to be able to group integrations together by the system they are connected to.
In order to support multiple request types on integrations - yet to maintain support for multiple modifications happening on one - we need to add a new wrapping "integrationGroup" around the current integrations - plus we need to move a few pieces of information into the integrationGroup so that they are shared across every integration within that group.
Integration groups should contain information such as:
{
"name" : "blogIntegration",
"description" : "Integrations to our blogging platform.",
"baseUrl" : "https://blog.domain.com",
"security" : {
... //See tickets around integrations security, not supported yet
}
}
In order to identify which integrations relate to this group - the existing integration configuration files must be stored within a folder of the same name as the integration group.
The integrations service must configure itself by looking for integration group files - identified as being named [groupName].integration.json - the example above would be called blogIntegration.integration.json. Once it has loaded these files it must then load each of the individual integrations related to that group by searching for config files within a folder that has the same name as the integration group.
The integrations service must host the endpoints configured on the integrations on the path /[groupName]/[integrationName] - so an integration called getPosts within the group blogIntegration would be hosted on /blogIntegration/getPosts.
The admin UI must be updated to allow people to add/remove groups, and when a user opens a group they must be able to see and modify all of the integrations in there - being able to add new ones and remove existing ones as required. This will require changes to both the admin and the kernel integrations source code management endpoints.
Integrations currently only allow for a single endpoint to be configured in isolation - this is not good as we need to be able to group integrations together by the system they are connected to.
In order to support multiple request types on integrations - yet to maintain support for multiple modifications happening on one - we need to add a new wrapping "integrationGroup" around the current integrations - plus we need to move a few pieces of information into the integrationGroup so that they are shared across every integration within that group.
Integration groups should contain information such as:
In order to identify which integrations relate to this group - the existing integration configuration files must be stored within a folder of the same name as the integration group.
The integrations service must configure itself by looking for integration group files - identified as being named
[groupName].integration.json- the example above would be calledblogIntegration.integration.json. Once it has loaded these files it must then load each of the individual integrations related to that group by searching for config files within a folder that has the same name as the integration group.The integrations service must host the endpoints configured on the integrations on the path
/[groupName]/[integrationName]- so an integration calledgetPostswithin the groupblogIntegrationwould be hosted on/blogIntegration/getPosts.The admin UI must be updated to allow people to add/remove groups, and when a user opens a group they must be able to see and modify all of the integrations in there - being able to add new ones and remove existing ones as required. This will require changes to both the admin and the kernel integrations source code management endpoints.