Skip to content

CreatingServiceList.md

Latest commit

 

History

History
112 lines (77 loc) · 5.69 KB

CreatingServiceList.md

File metadata and controls

112 lines (77 loc) · 5.69 KB

Creating the ServiceList

This is a step by step cookbook for creating the ServiceList.

Please, read the background information about the Concept of the ServiceList before working in the ServiceList.
Be aware that the template must not be altered outside the zones indicated by comments starting with '##'.

Preparation

  • If not yet existing, create an Issue for elaborating the ServiceList.
  • Open a local feature branch for elaborating the ServiceList.

File Handling

  • Assure that there is a copy of the latest template for the ServiceList in the develop branch of your application's repository. The latest ApplicationPattern+services.yaml can be downloaded from the ApplicationPattern repository.
  • Rename the file, by replacing "ApplicationPattern" by your application's name.

General

  • Re-using already implemented function at other applications is very much recommended.
  • Information about existing applications can be found e.g. in the GenericRepresentationApplication.
  • In case clarification about existing Operations would be needed, the responsible ApplicationOwner has to be addressed for complementing the documentation of his application.

HttpServer and TcpServer

  • Add the official ApplicationName and ReleaseNumber of the application.
  • Add fake address from official List.

OperationServers

  • Add OperationServers that are specific to this application.
    • Add the following two lines for every OperationServer the application shall provide:
    - operation-name:
      uuid:

ElasticSearch

  • If connecting a database would be required, add official Fake Index Alias from the List.
  • Otherwise, just delete the ElasticSearchClient from the ServiceList.

OldRelease

  • Add official ReleaseNumber of the operational version of the application. In case of new application, put the same value as in HttpServer above.
  • Add fake address of the operational version of the application. In case of new application, put the same value as in TcpServer above.

NewRelease

  • Add same value as in HttpServer above as the substituting ReleaseNumber.
  • Add fake address from TcpServer above as IP address and TCP port of the substituting release.
  • Add OperationsClients that will be required for handing-over the configuration information to the NewRelease.
    • Add the following two lines for every OperationsClient that shall be defined:
    - operation-name:
      uuid:
  • Fill in the OperationName according to OperationServer definitions from above.
  • Put them into execution sequence.
  • Fill in UUIDs according to structure of UUIDs.

From RegistryOffice to OperationKeyManagement

  • If your application would address one or several applications of the TinyApplicationController,
    • the following two lines for defining an OperationClient have to be added into the individual service section of the affected applications of the TinyApplicationController:
    - operation-name:
      uuid:
  • Fill in the OperationName, which shall be addressed.
  • Fill in UUIDs according to structure of UUIDs.

Further OperationClients

  • If further applications would have to be addressed, create additional entries into the clients list.
  • Take the last entry as a template (and delete it, if no longer needed).
  • Start with specifying the HttpClients and TcpClients.
    • Add the official ApplicationName and ReleaseNumber of the application, which shall be addressed, into the HttpClient.
    • Add a UUID according to structure of UUIDs.
    • Add the fake address of the application to be addressed to the TcpClient.
    • Add a UUID according to structure of UUIDs.
  • Add the usual two lines for defining an OperationClient to the operation-clients/service/individual section:
    - operation-name:
      uuid:
  • Fill in the name of the Operation, which shall be addressed.
  • Fill in a UUID according to structure of UUIDs.

Validation and Finalization

  • Double check your ServiceList.
  • Commit to your local feature branch.
  • Push your local feature branch to the remote repository.
  • Create a Pull-Request.
  • Please, regard the test results of the YAML linting in the Pull-Request. Correct the syntax of the ServiceList, if errors are indicated (warnings need not to be regarded), and commit and push again until the ServiceList in the remote repository is successfully validated.
  • Select a Reviewer from the team.
  • Assign the Pull-Request to yourself.