simulator-common contains an entity named ApplicationConfiguration which is used to manage the preferences of your application. This feature is used by the other functionalities of simulator-common, make sure to create the followig preferences within your database.
| Preference name (variable) | Description | Default/Example value |
| application_url | The URL used by any user to access the tool | |
| cas_url | URL of the CAS service | Default: https://gazelle.ihe.net |
| application_works_without_cas | Indicates whether or not authentication uses the CAS service | Default: false |
| ip_login | Indicates whether or not IP addresses are filted at login when CAS service is not used | Default : false |
| ip_login_admin | Regex used to filter IP addresses | |
| message_permanent_link | URL to access the messages exchanged with the tool | |
| time_zone | Time zone of the application | Default: Europe/Paris |
| svs_repository_url | URL of Gazelle Value Set repository | Default: http://gazelle.ihe.net |
| documentation_url | URL to get the user manual of the tool | |
| application_release_notes_url | URL to get the release notes of the tool |
A page is dedicated to the management of preferences, see /admin/configure.seam (only accessible by admin)
After having developed several simulators, we noticed that we always need an entity to store the messages exchanged between the simulator and the systems under test. In most of the case, we need to store the same informations (initiator, responder, message content ...) and we bind the simulator to a validator so we also store the result of the validation process.
A simulator offers several authentication methods, the basic method, the one we use on our server uses the CAS service available at https://gazelle.ihe.net. Other methods are:
The table below represents the boolean set in the database and the behaviour of the tool depending on their values
| application_works_without_cas | ip_login | behaviour |
| true | true | Only the users whose IP address matches the regex are granted as admin (ip_login_admin must be defined) |
| false | true | Authentication and rights are managed by the CAS service |
| true | false | Any user is granted as admin |
| false | false | Authentication and rights are managed by the CAS service |
If you have developed a model-based validation service to validate the messages exchanged in the context of the integration profiles implemented by your simulator, you can use this web service to allow other applications to call your validator. Using this class instead of creating a new one is easier for the clients since it's the same stub as for the other validation services.
The home page can be configured through the user interface (by admin) and the content is locale dependant.
Simulators can be driven by Test Management application. A web service is available that you must implement to allow Test Management to control your simulator.
To build the messages, your simulator may need values from a specific set of codes. We usually store those codes within the SVS Simulator and use the SVSConsumer utility class to retrieve the codes (based on OID).
Some messages must contain an XUA assertion in their header. Some mechanisms are implemented in simulator-common to help you with creating those assertions.
A REST webservice is available to retrieve information about a transaction instance.
If your simulator acts as an initiator, you will need to store the configuration of the system under test. An entity named SystemConfiguration is available to store those informations, it assumes that you need an URL to contact the system under test. If the system under test is HL7 based, you need to use HL7Common as a parent and not directly simulator-common.