Skip to content
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

docs: adjust process worker documentation #383

Merged
merged 2 commits into from
Aug 14, 2024
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
81 changes: 60 additions & 21 deletions docs/developer/09. Process Workers/01. application_checklist.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,6 @@
# Summary
# Application Checklist Process

## Summary

The application checklist process handles the registration process for a new company. The process steps are the following:

Expand Down Expand Up @@ -49,78 +51,115 @@ flowchart TD

The process worker communicates with the dim middle layer to create the wallet, or if disabled with the miw to create the wallet. It further more communicates with the bpdm, clearinghouse, the sd factory, the ssi-credential-issuer, keycloak, bpn did resolver and an universal resolver.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you please uppercase DIM in all place and explain what the abbreviation means once in the this file and also once in the dim_user_creation.md

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've adjusted the pronunciation and added the explanation for the abbreviation.


## VERIFY_REGISTRATION
## Process Steps

### VERIFY_REGISTRATION

The process step `CREATE_DIM_TECHNICAL_USER` is not triggered by the process worker it self, it will be processed either when the registration is approved via the endpoint `POST: api/administration/registration/application/{applicationId}/approve` or via the decline endpoint `POST: api/administration/registration/application/{applicationId}/decline`.

## CREATE_BUSINESS_PARTNER_NUMBER_MANUAL
### CREATE_BUSINESS_PARTNER_NUMBER_MANUAL

The process step `CREATE_BUSINESS_PARTNER_NUMBER_MANUAL` is not triggered by the process worker. It is triggered via the endpoint `POST: /api/administration/registration/application/{applicationId}/{bpn}/bpn`.

## CREATE_BUSINESS_PARTNER_NUMBER_PUSH
### CREATE_BUSINESS_PARTNER_NUMBER_PUSH

The process step `CREATE_BUSINESS_PARTNER_NUMBER_PUSH` retrieves the bpdm data and triggers the input/business-partners endpoint of the bpdm service. And triggers the setSharingState endpoint of the bdpm service.

## CREATE_BUSINESS_PARTNER_NUMBER_PULL
### CREATE_BUSINESS_PARTNER_NUMBER_PULL

The process step `CREATE_BUSINESS_PARTNER_NUMBER_PULL` fetches the legal entity from the bpdm service via the application id. If the legal entity doesn't have the bpn set the process will stay in `TODO`. If the bpn is set for the legal entity the process step is done.

## CREATE_IDENTITY_WALLET
### CREATE_IDENTITY_WALLET

The process step `CREATE_IDENTITY_WALLET` will only be executed if the dim wallet creation is disabled and the application checklist steps `BUSINESS_PARTNER_NUMBER` and `REGISTRATION_VERIFICATION` are done. The process step gets the companyName and businessPartnerNumber and calls the miw to create the wallet.

## CREATE_DIM_WALLET
### CREATE_DIM_WALLET

The process step `CREATE_DIM_WALLET` will only be executed if the dim wallet creation is enabled and the application checklist steps `BUSINESS_PARTNER_NUMBER` and `REGISTRATION_VERIFICATION` are done. The process step gets the companyName and businessPartnerNumber and calls the dim middle layer to create the wallet.

## AWAIT_DIM_RESPONSE
### AWAIT_DIM_RESPONSE

The process step `AWAIT_DIM_RESPONSE` is not triggered by the process worker. It will only be triggered by the endpoint `POST: api/administration/registration/dim/{bpn}`. The endpoint receives the did, the did document and the authenticationDetails for the created wallet. It than validates the did format and the schema of the did document, if one of those checks fail, the process will be set to failed. Finally the information are saved in the database.

## VALIDATE_DID_DOCUMENT
### VALIDATE_DID_DOCUMENT

The process step `VALIDATE_DID_DOCUMENT` retrieves the did from the database and validates it via an universalREsolver to check that the structure is correct.
The process step `VALIDATE_DID_DOCUMENT` retrieves the did from the database and validates it via an universalResolver to check that the structure is correct.

## TRANSMIT_BPN_DID
### TRANSMIT_BPN_DID

The process step `TRANSMIT_BPN_DID` retrieves the bpn and did. It than transmits the details to the bpn did resolver.

## REQUEST_BPN_CREDENTIAL
### REQUEST_BPN_CREDENTIAL

The process step `REQUEST_BPN_CREDENTIAL` gets the necessary data for the bpn credential creation and calls the issuer component to request the bpn credential. it will post a callback url for the issuer component to do the callback with the status of the credential creation.

## STORED_BPN_CREDENTIAL
### STORED_BPN_CREDENTIAL

The process step `STORED_BPN_CREDENTIAL` is only triggered via api `POST: api/administration/registration/issuer/bpncredential`, the issuer component sends an response to the credential creation regarding its success or error. If the creation was successful the process continues as displayed above. If it fails the process step is failed.

## REQUEST_MEMBERSHIP_CREDENTIAL
### REQUEST_MEMBERSHIP_CREDENTIAL

The process step `REQUEST_MEMBERSHIP_CREDENTIAL` gets the necessary data for the membership credential creation and calls the issuer component to request the membership credential. it will post a callback url for the issuer component to do the callback with the status of the credential creation.

## STORED_MEMBERSHIP_CREDENTIAL
### STORED_MEMBERSHIP_CREDENTIAL

The process step `STORED_MEMBERSHIP_CREDENTIAL` is only triggered via api `POST: api/administration/registration/issuer/membershipcredential`, the issuer component sends an response to the credential creation regarding its success or error. If the creation was successful the process continues as displayed above. If it fails the process step is failed.

## START_CLEARING_HOUSE
### START_CLEARING_HOUSE

The process step `START_CLEARING_HOUSE` retrieves the company did. If the wallet was created via the dim middle layer the did is retrieved from the database, if the wallet was created via the miw the did is retrieved via the `/api/wallets` endpoint of the miw. Than all necessary data for the `POST: /api/v1/validation` endpoint are retrieved from the database and the call to clearinghouse is executed.

## END_CLEARING_HOUSE
### END_CLEARING_HOUSE

The process step `END_CLEARING_HOUSE` is only triggered via the api `POST api/administration/registration/clearinghouse`. The clearinghouse sends an status to the portal with either the successful validation or an `decline` status. If the status is `DECLINE` the process will be set to failed, otherwise the process continues.

## START_SELF_DESCRIPTION_LP
### START_SELF_DESCRIPTION_LP

The process step `START_SELF_DESCRIPTION_LP` can be disabled with the `ClearinghouseConnectDisabled` flag in the config. If it is disabled the process step will be skipped. If it is enabled the sdFactory is called to request an self description document for the company.
The process step `START_SELF_DESCRIPTION_LP` can be disabled with the `ClearinghouseConnectDisabled` flag in the config. If it is disabled the process step will be skipped. If it is enabled the sd factory is called to request an self description document for the company.

## FINISH_SELF_DESCRIPTION_LP
### FINISH_SELF_DESCRIPTION_LP

The process step `FINISH_SELF_DESCRIPTION_LP` is only triggered via the api `POST: api/administration/registration/clearinghouse/selfDescription`. The sd factory will post the created sd document to the portal. The backend will save the sd document in the database and link it to the company.

## ACTIVATE_APPLICATION
### ACTIVATE_APPLICATION

In the process step `ACTIVATE_APPLICATION` the users of the onboarded company will be assigned with the correct roles for the portal as well as the bpn mapper in the central idp. After that the theme is set for the shared realm. The company application is set to active and the company is set to active. If it is an external company application, an `TRIGGER_CALLBACK_OSP_APPROVED` is created. All company admins will than be notified via the notification logic in the portal. And for the same users a [mail process](../Process%20Workers/mailing.md) is created.

## Retrigger

| Step Name | Retrigger Possible | Retrigger Endpoint |
| -------------------------------------- | ------------------ | --------------------------------------------------------------------------------------- |
| VERIFY_REGISTRATION | NO | |
| CREATE_BUSINESS_PARTNER_NUMBER_PUSH | YES | api/administration/registration/application/{applicationId}/trigger-bpn |
| CREATE_BUSINESS_PARTNER_NUMBER_PULL | YES | api/administration/registration/application/{applicationId}/trigger-bpn |
| CREATE_BUSINESS_PARTNER_NUMBER_MANUAL | NO | |
| CREATE_IDENTITY_WALLET | YES | api/administration/registration/application/{applicationId}/trigger-identity-wallet |
| RETRIGGER_IDENTITY_WALLET | NO | |
| START_CLEARING_HOUSE | YES | api/administration/registration/application/{applicationId}/retrigger-clearinghouse |
| RETRIGGER_CLEARING_HOUSE | NO | |
| END_CLEARING_HOUSE | NO | |
| START_SELF_DESCRIPTION_LP | YES | api/administration/registration/application/{applicationId}/trigger-self-description |
| RETRIGGER_SELF_DESCRIPTION_LP | NO | |
| ACTIVATE_APPLICATION | NO | |
| RETRIGGER_BUSINESS_PARTNER_NUMBER_PUSH | NO | |
| RETRIGGER_BUSINESS_PARTNER_NUMBER_PULL | NO | |
| OVERRIDE_BUSINESS_PARTNER_NUMBER | NO | |
| TRIGGER_OVERRIDE_CLEARING_HOUSE | NO | |
| START_OVERRIDE_CLEARING_HOUSE | YES | api/administration/registration/application/{applicationId}/override-clearinghouse |
| FINISH_SELF_DESCRIPTION_LP | NO | |
| DECLINE_APPLICATION | NO | |
| CREATE_DIM_WALLET | YES | api/administration/registration/application/{applicationId}/retrigger-create-dim-wallet |
| AWAIT_DIM_RESPONSE | NO | |
| RETRIGGER_CREATE_DIM_WALLET | NO | |
| VALIDATE_DID_DOCUMENT | YES | api/administration/registration/application/{applicationId}/retrigger-validate-did |
| RETRIGGER_VALIDATE_DID_DOCUMENT | NO | |
| REQUEST_BPN_CREDENTIAL | NO | |
| STORED_BPN_CREDENTIAL | NO | |
| REQUEST_MEMBERSHIP_CREDENTIAL | NO | |
| STORED_MEMBERSHIP_CREDENTIAL | NO | |
| TRANSMIT_BPN_DID | YES | missing |
| RETRIGGER_TRANSMIT_DID_BPN | NO | |

## NOTICE

This work is licensed under the [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0).
Expand Down
18 changes: 15 additions & 3 deletions docs/developer/09. Process Workers/02. dim_user_creation.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,6 @@
# Summary
# Dim User Creation

## Summary

The dim user creation handles the creation of technical users in the dim middle layer. The process steps are the following:

Expand All @@ -16,14 +18,24 @@ flowchart TD

The process worker communicates with the dim middle layer to create the technical users

## CREATE_DIM_TECHNICAL_USER
## Process Steps

### CREATE_DIM_TECHNICAL_USER

The process step `CREATE_DIM_TECHNICAL_USER` retrieves service account details from the database, those are the business partner number and the name of the service account and calls the dim middle layer to create a technical user on the dim side. A process id is send in the request to the dim to be able to set the service account data in the `AWAIT_CREATE_DIM_TECHNICAL_USER_RESPONSE`.

## AWAIT_CREATE_DIM_TECHNICAL_USER_RESPONSE
### AWAIT_CREATE_DIM_TECHNICAL_USER_RESPONSE

The process step is just a placeholder to retrieve the service account data on api level from the dim. The technical user will than be extended with the data that are retrieved from the dim middle layer.

## Retrigger

| Step Name | Retrigger Possible | Retrigger Endpoint |
| ---------------------------------------- | ------------------ | ------------------ |
| CREATE_DIM_TECHNICAL_USER | YES | missing |
| AWAIT_CREATE_DIM_TECHNICAL_USER_RESPONSE | YES | missing |
| RETRIGGER_CREATE_DIM_TECHNICAL_USER | NO | |

## NOTICE

This work is licensed under the [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0).
Expand Down
Original file line number Diff line number Diff line change
@@ -1,4 +1,6 @@
# Summary
# Identity Provider Provisioning Process

## Summary

The identity provider provisioning process cleans up the identity provider in the shared and central idp. The process steps are the following:

Expand All @@ -17,22 +19,36 @@ flowchart TD

The process worker communicates with the shared and central idp.

## DELETE_IDP_SHARED_REALM
## Process Steps

### DELETE_IDP_SHARED_REALM

The process step `DELETE_IDP_SHARED_REALM` deletes the shared realm based on the iam alias.

## DELETE_IDP_SHARED_SERVICEACCOUNT
## #DELETE_IDP_SHARED_SERVICEACCOUNT

The process step `DELETE_IDP_SHARED_SERVICEACCOUNT` deletes the service account of the identity provider from the shared idp.

## DELETE_CENTRAL_IDENTITY_PROVIDER
### DELETE_CENTRAL_IDENTITY_PROVIDER

The process step `DELETE_CENTRAL_IDENTITY_PROVIDER` deletes the identity provider from the central idp based on the iam alias.

## DELETE_IDENTITY_PROVIDER
### DELETE_IDENTITY_PROVIDER

The process step `DELETE_IDENTITY_PROVIDER` deletes the identity provider from the database.

## Retrigger

| Step Name | Retrigger Possible | Retrigger Endpoint |
| ------------------------------------------ | ------------------ | ------------------------------------------------------------------------------------ |
| DELETE_IDP_SHARED_REALM | YES | api/administration/registration/{processId}/retrigger-delete-idpSharedRealm |
| RETRIGGER_DELETE_IDP_SHARED_REALM | NO | |
| DELETE_IDP_SHARED_SERVICEACCOUNT | YES | api/administration/registration/{processId}/retrigger-delete-idpSharedServiceAccount |
| RETRIGGER_DELETE_IDP_SHARED_SERVICEACCOUNT | NO | |
| DELETE_CENTRAL_IDENTITY_PROVIDER | YES | |
| RETRIGGER_DELETE_CENTRAL_IDENTITY_PROVIDER | NO | api/administration/registration/{processId}/retrigger-delete-centralIdentityProvider |
| DELETE_IDENTITY_PROVIDER | NO | |

## NOTICE

This work is licensed under the [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0).
Expand Down
Loading