-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integration groups (apps) #136
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 calledgetPosts
within the groupblogIntegration
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.
The text was updated successfully, but these errors were encountered: