factory-api-dependencies
Service icon

Factory API Dependencies

Stable version 1.0.1 (Compatible with OutSystems 11)
Uploaded on 28 September 2023 by 
0.0
 (0 ratings)
factory-api-dependencies

Factory API Dependencies

Documentation
1.0.1

It keeps the same documentation as the previous version.

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 existing APIs (REST or SOAP) in the base of 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 agreed.

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.



1.0.0

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 existing APIs (REST or SOAP) in the base of 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 agreed.

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.