## 4 Concept Development
### Integration of Client Applications Using REST-Based Web Services  
The interaction of IT products with the platform and the openCDE-compliant interface is as shown in Figure 8. The given are an application A, the BIMSWARM platform and the openCDE-compliant data store. In the assumed initial situation, the associated toolchain is already executed all the way to application A. Sending an HTTP GET request from the application A the inquiring party can retrieve all executed toolchains for which application A is ready to start as step 1. An activity element is ready to start if it is itself in the status PENDING and all predecessor nodes are in the status SUCCESS. Since all requests to the platform are executed attaching the SSO token (see Section 4.7) within the authentication header, the requesting person is already identified. The list of toolchains is filtered according to the running toolchains to which the requesting person was granted access himself or via an organizational affiliation. In application A, depending on the respective implementation, either a toolchain can be selected by the user or a toolchain can be automatically determined for further procedures, for instance, if the list is to be processed in its order.  
In the following step 2, an HTTP PUT request is sent to the platform to change the status of the activity item to WORKING. The status of activity items can be tracked on the platform in the Composer. In step 3, an HTTP GET query is used to retrieve all metadata for the input data and their resources. Similarly, the query also provides information about the content locations of the output data. With these content locations, the results can be returned into the workflow after the operation is successfully performed in application A. The metadata also contain information about which schema, schema version and schema subset the files to be retrieved are in, and are supplemented with the corresponding media type, so that the data can be optimally processed further.  
Figure 7: Interaction between toolchain and openCDE-compliant data storage during restart.  
In step 4, the openCDE-compliant interface of the data store is used for the first time by retrieving all incoming content elements using HTTP GET on the route {project-root}/ containers/{containerId}/content/{contentId} with the respective ID of the information element. The partial route {project-root} is provided by the platform. The openCDE-compliant data store must therefore be registered as a product on the platform. In the current state of development, only a single data store can be used within a toolchain. In the future, however, different decentralized data stores can also be used within a toolchain for each storage element and networking with each other via the toolchain.  
Similarly, in step 5 the corresponding files are transmitted by means of an HTTP POST request to the routes of the respective outgoing content elements. Based on the metadata in the toolchain and in the information container, it can be clearly identified which outgoing data are necessary and where they must be stored. Thus, the next application can retrieve the information as input data. During these operations, the status of the activity element in the toolchain remains at WORKING.  
After all outgoing content elements have been filled, the status can finally be changed to SUCCESS in step 6. If errors occur during editing in the IT product or during transfer to the openCDE-compliant data store, it is also possible to send the status FAILURE via the REST API, which then signals to the Composer that the toolchain cannot be executed further at a certain point. Resetting to any previous step can be done via the Composer.