Rexroth Tightening
General
The Rexroth Tightening protocol is a message protocol for communication between Bosch Rexroth Tightening devices and services.
Technically, the data is sent as a JSON payload via REST. Only http is supported. The communication is unidirectional and always goes from the device to a service. The recipient is the client provides a REST API.
Information Router translates the incoming messages into PPMP messages which are subsequently forwarded to the consuming services like CPM.
Endpoint
The URI of the Information Router endpoint is built as in the following pattern:
https://{serverUrl}:{port}/connectivity/messaging/{apiVersion}/{tenantId}/rexrothtightening
The table bellow explains the components of the URI pattern.
| Component | Meaning | Supported Values | Example |
|---|---|---|---|
serverUrl |
The fully qualified name or IP address where the Information Router service is running. |
10.20.30.40 |
|
port |
The port on which the service is running |
443 |
|
apiVersion |
The version of the Information Router machine API. |
Current version: v1 |
v1 |
tenantId |
The unique identifier of the tenant to which the machine is assigned to. |
7311ea8c-5d48-43fe-acf9-980eedf24b6c |
An example URI is:
https://serverurl.com:8000/connectivity/messaging/v1/7311ea8c-5d48-43fe-acf9-980eedf24b6c/nexo
Message forwarding
During the forwarding of messages from Rexroth tightening controllers a conversion takes place that transforms the original Rexroth json to a standard PPMP version 2 (until Hub version 1.1.0) or version 3 (from Hub version 1.2.0) process message. The conversion for an average message takes a few milliseconds thus the throughput of the hub is less than for normal PPMP forwarding. The measured throughput with a general test environment is around 200 messages per second.
Additional notes
Message Payload
The Information Router service validates the received Ppmp request against the official Ppmp schemas and aborts forwarding if the payload is not following the specification.
The Information Router service validates the received Rexroth json payload against the official schemas and aborts forwarding if the payload is not following the specification.
Authorization Header
For the authentication to work a user has to be created via the Access Management menu on the Portal. The user must have the MACMA Connectivity Machine User role assigned to it. After creating the user, please log in with te newly created user to the portal and change its password.
The HTTPS request must contain a Basic Auth authorization header, which contains the credentials as Base64 encoded username and password of the machine, separated by a colon.
Example:
-
Username: user
-
Password: password
-
Base64 encoded username and password separated by colon ("user:password"): "dXNlcjpwYXNzd29yZA=="
-
⇒ Authorization Header: "Basic dXNlcjpwYXNzd29yZA==""
Requests sent to the RexrothTightening endpoint currently doesn’t need to include the authorization header as the Rexroth controllers can’t do it.
Status Codes
The following table contains the status codes which can be returned to the machine.
| Status code | Meaning |
|---|---|
200 - OK Success |
In case of the asynchronous mode, the message was successfully received by the Information Router and the machine authorized in MACMA, using the provided username and password. For the synchronous mode, it also means that it was successfully sent to all target endpoints configured for that route. |
401 - Unauthorized response |
The machine with the provided username and password in the authorization header of the request could not be successfully authorized in MACMA. |
500 - Internal Server Error |
Un unexpected error occurred, the body contains the exception message itself. |