chore(docs): docu guru - some smaller doc fixxes and adding outdated …

…tag.

docs/src/docs/arc42/building-block-view/whitebox-overall.adoc

@@ -1,14 +1,17 @@
 = Whitebox overall system
 
-== Component diagram
+== [Outdated] Component diagram
 
 [plantuml, target=whitebox-overview, format=svg]
 ....
 include::../../../uml-diagrams/arc42/building-block-view/whitebox_overall.puml[]
 ....
 
-== Component description
+== [Outdated] Component description
+
+|===
 |Components |Description
+
 |IRS
 |The IRS consumes relationship information across the CX-Network and builds the graph view. Within this Documentation, the focus lies on the IRS
 
@@ -23,3 +26,4 @@ include::../../../uml-diagrams/arc42/building-block-view/whitebox_overall.puml[]
 
 |IAM/DAPS
 |DAPS as central Identity Provider
+|===

docs/src/docs/arc42/cross-cutting/development-concepts.adoc

@@ -34,8 +34,7 @@ The generated OpenAPI specification file is automatically compared to a fixed, s
 
 == Migration
 
-There currently is no data migration mechanism for TraceX.
-In case the model of the persisted data (Jobs) changes, data is dropped and Jobs will need to be recreated.
+Data Migration is handled by flyway.
 
 == Configurability
 

docs/src/docs/arc42/scope-context/technical-context.adoc

@@ -13,7 +13,7 @@ In order to use Trace-X frontend with Trace-X backend, users need to authenticat
 By the frontend UI users provide valid credentials and the system generates a bearer token that it gets from Keycloak and attaches it to the HTTP header parameter Authorization.
 Then once a user is authorized and has proper role within Trace-X backend, the backend delegates HTTP calls to specific service in their behalf as technical user in order to fulfill specific functionality.
 
-=== Registry API
+=== [Outdated] Registry API
 
 [plantuml, target=technical-context-registry, format=svg]
 ....
@@ -34,7 +34,7 @@ include::../../../uml-diagrams/arc42/scope-context/technical-context/irs-api-vie
 The Trace-X acts as a consumer of the IRS component. The Trace-X contains a Restful client (REST template) that build a REST call to the mentioned IRS API based on its known URL (the IRS URL is configurable in the Trace-X).
 Request contains details required to start IRS fetch job provided by the component during assets synchronization. Like described in the above section, the security aspect is required in order to achieve a REST call against the IRS. As a response, the Trace-X gets the created job id and periodically pulls for the job details that contains assets that will be uploaded to the system. And as mentioned above, the transport protocol HTTP(S) is used for the REST call communication.
 
-=== Portal API
+=== [Outdated] Portal API
 
 [plantuml, target=technical-context-portal, format=svg]
 ....
@@ -44,7 +44,7 @@ include::../../../uml-diagrams/arc42/scope-context/technical-context/portal-api-
 The Trace-X acts as a consumer of the Portal component. The Trace-X contains a Restful client (REST template) that build a REST call to the mentioned Portal API based on its known URL (the Portal URL is configurable in the Trace-X).
 Request contains "bpns" provided by the component during sending notifications. Like described in the above section, the security aspect is required in order to achieve a REST call against the Portal. As a response, the Trace-X gets the corresponding BPN mappings to EDC urls where a notification should be send over. And as mentioned above, the transport protocol HTTP(S) is used for the REST call communication.
 
-=== EDC API
+=== [Outdated] EDC API
 
 [plantuml, target=technical-context-edc, format=svg]
 ....

docs/src/docs/arc42/solution-strategy/structure.adoc

@@ -6,8 +6,14 @@ It roughly can be broken down into the following parts:
 * Asset controllers to get the asset information
 * Dashboard controller to get dashboard related summed up information
 * Registry controller to fetch assets from the Digital Twin Registry
-* Notification controllers to get notification information
+* Notification controllers to get notification information and create edc notification offers
 * Submodel controller for providing asset data functionality
+* Import controller for importing trace-x data for data provisioning.
+* Contract controller to get information about contract agreements
+* EDC controller to retrieve notifications
+* IRS Callback controller to retrieve asynchronous jobs completed by IRS.
+* Policy controller to retrieve information about policies
+* BPN controller to retrieve information about business partners
 
 The backend does a request to the Digital Twin Registry utilizing the Registry controller. Extracted data from the response is made available through the Asset controller and the Dashboard controller to the Frontend.