Please enable JavaScript.
Coggle requires JavaScript to display documents.
API Standardisation and Externalization (Understanding via Grooming…
API Standardisation and Externalization
GET calls to be externalized for Issue Management
Refer to the IM details in the sheet
Incremental changes to be fetched from Medidata platform
ICON - For ensuring data sync between IM and their own systems
How are we planning to Integrate with ICON's Data warehouse ? How do we simulate this in sandbox ?
Only Base level services will be exposed for IM
Issues API
Actions API
Architecture - Considering Incremental polling
:question:
Refer to the first considered solution in th data sync page
Testing ICON GET requests, re-routing through external gateway
Testing authentication of the external gatway via mauth
Through App to App authorization
Testing the internal existing set-up :question:
Request to one of the base services via the ext gateway traversing through Amazon API gateway
Request to one of the base services via the ext gateway traversing through AWS Lambda
AWS Lambda consulting AWS Dynamo DB and AWS KMS for calling API's internal to SIM/IM
How do we test if Incremental fetch is really happening if requests re-routed through External API's ? :question:
What is the frequency with which the external API's poll SIM/IM services ?
:question:
Understanding via Grooming sessions
Instead of exposing the actual SIM/IM API's to external clients, they will be exposed through an API gateway
The external gateway works as a proxy. Requests come to the API gateway and then this request is re-routed to specific SIM/IM services
Prospective gateway URL: gateway.mdsol.com/issues . This could be re-routed to issues API to fetch the list of issues
ICON wants to take our Issues, Actions and Comments and put it on their systems. This is a case of exposing our services
Sample Use Case: ICON can ask IM to fetch the list of all issues created after a particular date and IM should be capable of catering to this request
API contracts will be exposed to the customers Eg: ICON
To expose our API’s through the API gateway, forAPI’s we have, we would change our openapi.file and put external.mdsol.com against the end points which will be externalized. A Doc will be generated.
Changes made by us to the external API's will be put into a message queue Eg. Could be Archon which is a pub sub service. ICON reads from Archon and understands the new change available
Filters will have to be added to the current API's to add an end point for the context. Eg: Give me all the created issues for this CDS at this date
External apps will not have the proper impersonate. External apps will use app to app auth via external gateway
API Standardization and Externalization is only for GET requests for now
Each client will have a seperate queue for sending requests to the gateway. This is a different architecture
All the clients need data incrementally
Probable first steps for ICON set-up
Any external app talking to us has to be reg with mAuth
Create a config type for env, create config type role
Role will be a std role - has to be created on cloud admin - Rave task on Dalton to create the role and this role is assigned to the external app. This role is at CDS level
GET calls for Settings are externalized too - needs testing
External App cannot directly request us, it has to come thru the external gateway
External flag for all the endpoints in our openAPI doc. In our release process, they scan all the openAPI files, read the external ones and put it in some universal OPENAPI file which belongs to the client and generate the doc for us
What could be the probable Test setup ? Will we be testing this feature on sandbox , on develop environment itself
We should be testing on sandbox-develop. Mock service kind of a thing will be built and authenticated with m Auth . Stories would be required to create this mock setup. By IM sprint teams and Team 10
What is the max length of a URL which can be passed via the the gateway ?