In summary, the purpose of this component's process is to identify all existing APIs (REST or SOAP) (exposed or consumed) by the Outsystems platform, and make them available in a quick reference database, so that the IT team can map the impacts of changing APIs or EndPoints in the APIs.
The process consists of the following steps:
1. timer Timer_APIDependenciesLoad:
1.1 This Timer should run once a day in the early hours of the morning (03:00AM) and query all the APIs (REST or SOAP) in the current OutSystems environment.
1.2 To do this, we use the ExtendedMetamodel component to access the tables hidden by the Outsystems platform.
1.3 This Timer will create the records in the APIServiceMapping table;
2. At the end of the Timer above, the Timer Timer_APIDependenciesLoadWebMethods is woken up.
2.1 This Timer will identify all the Spaces that have APIs (REST or SOAP) published;
2.2 We will use the OutDoc component to read the identified Spaces;
2.3 For each Space, the OML is read and the XML is collected;
2.4 With the XML, we read all the APIs (REST or SOAP, Expose or Consume) and identify the API details, as well as the list of EndPoits for each API.
2.5 We save the list of EndPoints in the APIServiceMappingWebMethods table;
2.6 We then have all the APIs in the environment available for consultation in the APIServiceMapping and APIServiceMappingWebMethods tables;
2.7. The IT team can use a back-office application to assess the impact of changes to APIs and their EndPoints on the OutSustems environment.
The purpose of this application is to enable the IT team to identify all the API dependencies involved in the company's OutSystems projects.
Improvements to the component, to cater for environments running on SQL Server, Oracle and MySql database servers.