Naming exchanges and routing keys

[gitting-around]

So far the exchange name and routing key parameters are fiddled with inside the RMQFMU, to result in the actual routing keys and exchange names.

E.g., if the exchange name parameter is set to fmi_digital_twin, then it is extended to fmi_digital_twin_cd for the content data connection, and fmi_digital_twin_sh for the health data connection.
Since we discussed that we might remove the system health connection now that we have the osmc, then the exchange name provided in the model description will be the actual one, used in the connection. Until this is implemented, we should call that parameter exchange_name_prefix, to avoid any confusion for the user.

Similarly, for the routing key, it is actually a prefix, rather than the used routing key, and serves as a base for the pub/sub routing keys for the content data, and as a base for the pub/sub routing keys of the health data. If we remove the health data, then we still need to set two routing keys instead of one. Even here the first step would be to call that parameter a routing_key_prefix, rather than a routing key. I am not sure if there can be some other to tackle this.

[CThuleHansen]

Default exchange is the one provided and the health data is extra. I.e. if the user provides fmi_digital_twin, then fmi_digital_twin for content data and fmi_digital_twin_sh for health data.

For routing keys, I actually think it should be similar. Specify a routing key for publishing, and specify a routing key for receiving.

In total, this requires ONE extra parameter.

[CThuleHansen]

Keeping it, it is 2 parameters rights?

[gitting-around]

Keeping it, it is 4 more, 1 for the exchange of health data, 2 for the routing keys of health data (send &receive), and the one routing for the health data.

[CThuleHansen]

1 exchange for content data, 1 exchange for health data. Same routing keys on both exchanges.

[gitting-around]

fair enough, this seems reasonable.

[hejersbo]

We should still decide if the health data is to be kept. I don't think we plan to use it for the ongoing plans regarding time discrepancy detection (as far as I remember). But it may of course still have some other uses?