Basically all resources in FORCE Bridge API have an ID. Almost without exception, this is a universally unique identifier (UUID), since domain-specific IDs, such as the order number of a production order, are only unique in a specific context. The ERP context in which an order number is unique depends on the respective ERP system. In SAP ERP, for example, order numbers are unique within the client, but not within the overall system.

An exception are some master data whose ID is not a UUID because semantics plays a role in these cases. For example, there are 2 workplace states, one with the ID “PRODUCTION” and another with the ID “DOWNTIME”. Application developers can be sure that these two workplace states exist on every instance of a Bridge API compatible IoT platform.

Master data such as the workplace state also have a numerical code. The code for downtime and production can be arbitrarily defined in any production plant. In a production plant, it serves to have a unique numerical code for standstill and production across the different languages. For an application developer, however, the code has no significance because of its arbitrary and company-specific definition.

This raises the question of why the code is included in the API at all. The reason for this is the following: If an application represents the workplace state or the detailed operating states in a user interface , the representation should possibly also include the respective code. In this case, the application developer must also be able to access the code.