NOTE: If you have a DEMO or Developer license this topic does not apply to you as you cannot install or run the MS Windows Services and must only Run Locally.

 

 

CORE HL7 Schema Engine Windows Services:

 

In this software, as we do with almost all of our commercial HL7 software products, we provide the client with multiple "Primary" MS Windows services, as of version 3 that number is up to 20 "Primary" windows services as well as the ability to create a "Private" service. The services all perform identically and there is no particular need to favor one over the other. As you create schema profiles you will notice in the footer the area where you assign that schema profile to a windows service (see screenshot below).

 

 

 

 

You can create multiple schema profiles assigned to the different services or you can assign all of your schema profiles to the SAME service and only have to manage one Windows service.

 

There are several very important things to keep in mind when running the Schema Engine MS Windows Services. Most of them have to do with HOW Microsoft Windows Service applications run and the different user security configurations possible in the different MS Windows operating systems. You see, MS Windows Services are run in their own memory space by the operating system and usually under a different 'User' context than your own Windows/Network User ID. This can sometimes create confusion and might cause some conflicts which are not readily apparent. If you do have issues the symptoms are usually that everything runs fine when running locally BUT do not work when running as a service.

 

1.Installing or Removing the Schema Engine services. When performing either of these actions you MUST be logged into Windows with a User ID with sufficient 'security' rights to allow this. If you try to install or remove the services and the action fails contact your system administrator for assistance.

2.Using MS SQL Server security. If you selected 'Windows Logon (Trusted)' when you created your Schema Profile then not only must you be logged into Windows with a User ID that actually HAS a trusted connection to the database but the Schema Engine Windows Service(s) must ALSO be configured to run under the context of a Windows User ID which has a trusted connection to the SQL Server AND appropriate access to the Schema Database and Tables. We recommend that if at all possible you use the 'SQL Server User ID' option when creating your schema profiles which means that the Schema Engine will use MS SQL Server security when connecting to the SQL database. Speak with your DBA if you are unsure how to do this. If you are not able to use a MS SQL Server user id then you MUST configure each of the Schema Engine services to run under the context of a Windows/Domain user which does have a trusted connection to the database. To do this, right click on each service and select 'Properties' and then fill out the 'Log On' tab with the appropriate information.

 

Installing Or Removing the Windows Services:

 

 

To install the services just click the Install Services button. To remove the services click the Remove Services button. Neither of these buttons will be enabled unless they CAN be clicked. For instance, if you have no services that have been installed, the Remove Services button will be disabled. If all services that need to be installed have been, the Install Services button will be disabled. If your Windows services are running both buttons will be disabled.

 

IF you try to install or remove your services and it fails for some reason (typically because you are not logged into the computer as a user with sufficient rights) you can open a Services Report (the  button on the toolbar) and it will show the necessary Windows commands to install / uninstall each windows services.

 

 

 

Primary Service Instances

 

In the CORE HL7 SQL Schema Engine we provide 2 different types of Windows Services. There is the Private Service and there are up to 20 different Primary Services.

 

While a Private Service can only run 1 Postmaster, you can theoretically assign as many Schemas as you like to a Primary Service Instance. There is right or wrong answer to which path you choose here as you create your Schema Profiles, it's all a matter of personal preference based on your HL7 mission(s). There are some important caveats to consider IF you have (or intend to have) many HL7 Schemas, here are a few.

 

Adding a New Schema. If you ADD a new Schema and assign it to a Primary Service Instance which is Running you have to RESTART that Primary Instance in order for the service to "see" your new schema. While this interruption to your other Schemas in that service will be very short, it will still be there . This is very easy to do, you can just Right Click on the Service Instance and use that menu to STOP just that service and then START it again.

 

Editing an Existing Schema. This can be a little more tricky than adding a new Postmaster. If a Postmaster is currently running in a Windows Service you cannot edit it if you want to make changes without first STOPPING that service. That service has to stay STOPPED until you have finished editing the Postmaster then restarted so that the service can "see" your changes. This can be problematic if the Primary Service running your Postmaster is also running some other high value or high volume Postmaster(s) running HL7 interfaces which you cannot allow to be stopped for any length of time.

 

Testing and Troubleshooting. This scenario falls into the same category as editing a Schema Profile. When troubleshooting problems you may have to edit and run your Schema several times, and you might want to Run your Schema Locally while doing this (which you CANNOT do if the Schema is running in a Service.

 

Too Many Windows Services. By allowing you up to 20 Primary Service Instances PLUS the ability to create the Private Services, you can theoretically create as many different CORE SQL Engine Windows Services as you like and use each one to only run a single Schema profile. There is a very important caveat here and we cannot define that for you because it will be based on the performance of the computer running the CORE HL7 SQL Schema Engine software. This has to do with the amount of time it takes to Start, Stop, and Refresh the windows services (particularly the Refresh). Your SQL Engine software will Refresh the Windows Service(s) Status a LOT, not just when you click the refresh button () on the toolbar. Whenever you try to edit a Schema Profile, Run Locally, Run a Report, even every time you switch to the Windows Service(s) Status tab in the main window. The more SQL Engine services you have, the longer that operation will take, so you should limit the number to whatever your personal tolerance allows.

 

Solutions. None of this really matters unless you have (or plan to have) more than 20 HL7 Schemas running. We have customers who run literally hundreds of HL7 Schemas on a single server. As a general rule of thumb we don't recommend that you create more than 40 SQL Engine windows services (20 Primary and up to 20 Private Services). If you are running 220 different SQL Schemas in this scenario you can have 20 in a private service and 200 evenly distributed amongst the 20 Primary Services. This way, in the event that you have to STOP a Primary Service it will only affect 10 of your customers.

 

Use a Verify and Promote strategy with the Private Services. Whenever you need to create a new HL7 Schema Profile, or troubleshoot an existing Profile, even if you just need to edit a Schema Profile and you don't know how long that will take, assign it to a Private Service. Keep it assigned to the private service while you test and Verify that everything is working correctly and once that is done, you can Promote that Schema by removing the Private Service and assigning it into a Primary Service Instance at your leisure.