There are some properties that do not belong to any particular component, but to the entire solution. These are called solution-level properties. In the MD Link Studio, they can be edited by going to the Edit menu > Properties, or by clicking on any blank space in the graphical pane on the left. The solution-level properties will then appear on the right.
Descriptions of each solution-level property follow.
These are fields provided for your convenience, should you wish to make any notes on this solution.
If this box is checked, then as soon as the MD Link server is started (no matter which invocation method is used), then the server will load this solution automatically. (This only happens if this solution file is stored on disk directly within the data folder's solutions folder; subfolders of solutions are not scanned for auto-load solutions.) Most production users will want to use this option on their essential solution files, to avoid having to manually start them after downtime.
Care should be taken with this option, especially if one's workflow with the Studio involves saving multiple versions of a solution file with different file names. One could accidentally have multiple nearly-identical solutions all with auto-load on. The order in which solutions are auto-loaded is not defined, and so one's old version of a solution could be loaded before the new one - and thus bind to a certain HL7 Server Socket port number first, for example, thus grabbing message traffic that was intended for the production solution.
This enables one to delay the auto-loading of the solution. This option takes effect only at server startup time. As some large solution files can take minutes to load, and in a high-load scenario the MD Link server may be bogged down while catching up on a backlog of messages, this option is intended to help in these situations when it is desirable to give priority to one solution to another.
Here one can set the log filter level for this solution. There are five log levels; from lowest importance to highest, they are: DEBUG, INFO, WARN, ERROR, and AUDIT. To set the log filter level means that only log messages of the given level or higher will be emitted (that is - recorded in the database, and shown in the monitor). For example if the level is set to INFO then INFO, WARN, ERROR, and AUDIT messages will be emitted. See this page for more information on log levels.
If this option is set to "Use the server's default filter level" - then the server's global log level is used. This is settable through the Monitor by right-clicking on the server node and selecting "Change Server's Global Filter Log Level".
Note that this is a server-only option, so it does not apply when running a solution in the studio. Use the log level slider in the studio's log window for that.
This is the solution-global switch for the performance feature known as performance grouping. Performance grouping is intended to reduce a certain bottleneck in many MD Link solutions - reading from and writing to MD Link's internal persistence database.
The way that this option works is by grouping certain tasks and resources together and executing them as a single unit of work - thus avoiding consulting the persistence database (for input queues and output messages) every step of the way. A performance group is typically several tasks in a straight row, from the top down. For a performance group, the engine will internally maintain only one input queue - at the top task - and will write output messages to the database only at the bottom task, rather than maintain each of these for every task and resource.
In short, the goal of the performance grouping option is to increase a solution's message throughput by minimizing unnecessary reads and writes to the engine's internal persistence database.
What is deemed 'unnecessary' is decided partly by the solution author, and partly by the engine. The engine will only group together tasks and resources that are considered 'groupable'. Generally speaking, tasks that effect anything external to the engine (such as the HL7 Socket Task, or the File Writer Task) are considered not groupable, whereas tasks with no such external effects, but which only manipulate data within the engine, are considered groupable (such as the HL7 Parser Task, or the Text Splitter Task.) Some tasks types leave it for the solution author to decide whether they are groupable or not - such as the Custom Task, Shell Task, and JDBC Call Procedure Task.
The solution author can always disable all performance grouping for a solution by turning off the solution-level option here.
Performance groups are determined when the solution is loaded, and will not change while the solution is loaded. If the solution-level performance grouping option is on, a log message will be written at solution load time which will note which components are being grouped together.
This option enables writing of performance and message traffic statistics to the internal persistence database. The GUI Utility for viewing statistics is accessible from the Monitor’s tree view (Server, Solution, and Component Nodes).
These are options that control the automatic deletion of data from MD Link's internal persistence database. MD Link writes three kinds of data to this database: message data, log data, and statistics. Message data consists of the XML messages output during runtime by every event, task, and resource in each MD Link solution. By default, every one of these for every message is written to the database. See the 'performance grouping' option for exceptions to this rule. Log data consists of the human-readable messages that inform you of what is happening inside their solutions. Statistics refers to the data used to generate the statistics graphs that are viewable from the Monitor.
The disk space required for message and log data generally increases as your message volume increases. The disk space required for statistics, however, does not. It is small and constant.
The auto-purging options should be set according to one's needs with regards to data retention. The setting for message data is likely the most critical of these, because once message data for a particular transaction has been deleted, it naturally cannot be examined or resubmitted.
MD Link performs autopurging in the background, and does not interrupt the normal business of running solutions.
MD Link does not perform auto-purging at any particular time of day - in fact, it makes an effort to spread out the autopurging of different solutions throughout the day. The number-of-days parameters here are therefore approximate. MD Link will generally not autopurge data as soon as, or even within several minutes of, the cut-off point in time when the set number of days has passed - but MD Link will wait at least that long, and will generally autopurge the data in question within 24 hours of that idealized cut-off point in time.
MD Link will autopurge the data of a solution even if that solution is not loaded. The autopurge settings used will be those that were in effect when the solution was last loaded.
Autopurging is part of the server process, so it will not be performed while the server is not running. If the MD Link server is left shut-down for several days, then a backlog of data to be purged may accumulate. MD Link will start catching up on this backlog when the server is started. It will not attempt to do this catching up all at once, right away, but rather will do it gradually. A significant backlog may take several days to clear. If this is a problem, then one should use the manual purging tool instead.
This option is present to assist those with a large number of components and/or solutions, to control the order that components appear in the tree view. However keep in mind that the Monitor also shows a 'studio view' (i.e. graphical solution layout) of the solution when you hover the mouse over component nodes in the monitor's tree. This studio view is shown via a popup-style window and components in it can be selected via a mouse click, and this selection will be reflected in the tree.
Here is where you enter information for MD Link's e-mail alerts. Alert conditions are defined at the component level, but the default e-mail addresses to send the alerts to, and the SMTP server to use for this, are defined at the solution level, here.
Here you can also set the "time windows" during which alerts are active, and control the e-mail digest threshold to limit the number of alert e-mails that you receive.
You can override the solution-level e-mail addresses and time windows from an event's or task's Alerts tab.
The File Format Version is maintained for supporting backward compatibility of the MD Link solutions. This means that solutions created with an older release of MD Link can always be loaded with a newer release of MD Link. However, solutions created with a newer release of MD Link generally cannot be opened with an older version of MD Link.