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 service is started, the service 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 service startup time. As some large solution files can take minutes to load, and in a high-load scenario the MD Link service 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 service's default filter level" - then the service's global log level is used. This is settable through the Monitor by right-clicking on the service node and selecting "Change Service's Global Filter Log Level".
Note that this is a service-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.
This option works 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 (Service, Solution, and Component Nodes).
If your solution has the "Index component output for fast searching" checkbox selected in the Studio, then your searches in the Monitor's Output Messages tab will tend to finish quickly. This checkbox is also known as the "fast search" feature.
It is implemented at the solution level and in the MD Link Service backend. There is nothing you need to do in the Monitor in order to benefit from "fast search". (It is possible to disable use of "fast search" in the Monitor from the "View" menu, but this option is intended for rare troubleshooting scenarios rather than everyday use.) The "fast search" indexing is done in the background of the MD Link Service / service. There is a performance impact for enabling it, but it is a negligible one - approximately 3%.
Checking this box will make your searches in the Monitor finish much faster, especially if you have high message traffic and/or a long auto-purge period for message data. In many cases, a search that will take over a minute to finish if you have this checkbox deselected will finish in one second if this checkbox is selected. With this checkbox selected, the time that searches take to finish is constant, rather than proportional to the amount of data that you are searching. Therefore if your searches of Output Messages tend to take about three seconds when you are retaining one month of data, then they will still take three seconds if you later decide to retain six months of data.
There is no corresponding checkbox for log data at this time, so searches in the History Log tab will tend to be slower. There is also no corresponding checkbox for input queues, but searches in the Input Queue tab tend to finish quickly regardless.
See this page for more information.
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 service process, so it will not be performed while the service is not running. If the MD Link service 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 service 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.
E-mail digest
The e-mail digest feature prevents MD Link from sending you too many e-mails. After N e-mails, the e-mails are held in MD Link until the current five-minute time window is finished, and then all of the relevant alert information is sent in one e-mail.
For example, say you have a solution which contains a Custom Task with its alert setting for "Task execution failure" set to "Error". Also, say you have set the (solution-level) e-mail digest threshold set to 2, then you load the solution, and the Custom Task executes and fails ten times within a few seconds. In this scenario, you would get e-mails right away pertaining to the first two errors. Then, almost five minutes later, you would get a single digest e-mail pertaining to the remaining eight errors.
If your Custom Task failed three times, then you will get a digest e-mail containing only one alert. This might seem confusing, but it shouldn't be. It will be titled a "digest" because it was sent at the end of a five-minute window, rather than right away.
Either way, at the end of each five-minute time window, the internal counter will be reset. MD Link will again send individual e-mails right away as the errors happen - until the third error, which will be delayed until the next five-minute window is finished.
If your task throws different kinds of errors that get grouped together into a single digest e-mail, you will see a breakdown of each type of error.
The five-minute time windows are aligned from the time when the solution was loaded. Therefore they will rarely coincide with
Note that this option - as with e-mail alerts in general - operate only when the solution is loaded in the Service. Not the Studio.
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.