· Feb 15

Comparing code on running servers

Is there a way of comparing code running on two Ensemble servers - ideally excluding certain types of difference?

We are a new team working in HealthCare (lots of HL7, some web-services). As well as doing new development on local servers with suitable source control, we have a large code base we've inherited from an external supplier for which we have no log of versions or differences. We have a live server and test server - and we've stumbled across a couple of places where there are differences in logic in addition to the expected differences in endpoints. Is there any way of systematically comparing the code running on those two servers, so we can identify all the differences? Eg a script to run against exports of the code created on the two servers that intelligently compares and highlights differences, but excludes things like differences in endpoints?

Product version: Ensemble 2018.1
Discussion (9)2
Log in or sign up to continue

Hi Colin,

I created a utility a few years back which I have open sourced to:

It will show significant differences in Classes, Routines, Lookup Tables, HL7 schemas, Include files, Namespace mappings.

ie: It is clever to ignore non-functional differences for example:

  • Comment lines,
  • The order of routine line labels or method definition

This helps a lot for uncontrolled environments where updates have been integrated manually, in a different order.

The SQL profile can help diff anything with a SQL projection so can include: Production settings, Schedule Tasks, CPF, etc.

It works with flatfile exports and imports, so systems can be disconnected / on different networks.

Will happily diff 5 or 10 systems side-by-side.

The intention is for a client install that only includes the profilers and schedule.

Meaning the reporting side web pages do not need to be installed to servers only being profiled for difference signatures.

If needed it can effect code diffs just via the thumb-prints, without exporting actual code, useful for secured code scenarios.

Also if looking to upgrade Ensemble, there is a zero-install version of same compare tool that might highlight some useful platform differences



I usually follow these steps when I have two similar but distinct codebases:

  1. Create a new repo.
  2. Export everything from the LIVE server into the repo. Commit.
  3. Export everything from the TEST server into the repo. Commit.

Commit from step (3) would have all the differences between LIVE and TEST. I assume the code on TEST is newer, so that should be a later commit, but it you want to, you can swap the export order.

Before making a commit (3) you might want to remove trivial differences such as whitespaces, etc. Also Gitlab has a compare mode for commits which automatically ignores whitespace differences.

Thanks for suggestions so far.

One challenge is our organisation is very wary of installing any additional code (as Alex suggested) or hooking up something like VS Code, to the live server, which is passing patient information between the various hospital systems... The test system has a little more flexibility, but organisation is a bit twitchy!! Would a plausible path be to sort of follow Eduard's suggestion, but:

  1. Export code from live (an export of the classes via Management portal, or if better an export via Studio) to XML
  2. Export code from test (as above) to XML 
  3. On a local laptop, import live code to a newly created namespace and commit from there to a GitLab repo
  4. On same local laptop, import test code and commit from there to the GitLab repo
  5. Compare as suggested....

Ompare can also be run against exports that had been re-imported to clean namespaces for profiling locally.

It won't help for comparing namespace mappings or SQL, but it could still do the Lookup table differencing for you.

The approach either GIT / Ompare for actual diff is one choice.

With regard to achieving an export, I would suggest to use Studio on the target Ensemble Instance to create a "Project" for exporting.

Then add the respective Classes, Routines, HL7, include, Rules and any other components.

For lookup tables if the version is too early for visibility of "LUT" types, these can be exported by manually adding for example: Ens.LookupTable("MyTableName").GBL to the project, for each lookup table.

If you have a project on the server it is less error prone and quicker to have an existing export project to add items next time.

When you import with studio to report instance / git instance, you will have opportunity to double check which items you do actually want to import.

Hope that helps.

Thanks all for responding. Really only adding this message so I can try and mark the question as answered - since there are the two approaches (ompare and using git/repo tools), not wanting to mark one or other as the answer, since both have merits and may be helpful for different situations. I suspect we'll try the git/repo tools approach first, given our particular mix of platform and experience.