UDL Support

    Have you ever wondered why you are writing code in Caché Object Script, and it is exported to an XML file?

    So, it's time to change. Starting with the release of the new Atelier development environment and version Caché 2016.2, you will have the opportunity to export and import files in the format that you write in the studio, the so-called UDL (Universal Definition Language) format. Now you can write code that is not only fast, but also pleasing to the eye when exported. But, another, no less important problem arises: if all new projects will be in the UDL format, then who cares about backward compatibility?

    let's start

    InterSystems takes the issue of backward compatibility very seriously, so we decided to give new life to some old projects and add a new feature - working with UDL.

    As you can see in the picture - COS exported to XML, on the right - UDL:

    Caché source control

    The first in line was a rather simple, but very useful project called Cache Source Control. Its task is very simple - take all the project files and export them to some folder after each successful compilation, as well as import new files that appear in the folder. Prior to rebirth, this version control could export files in two formats:

    • xml - all files had the extension .xml
    • (cls, mac, int, dfi) .xml - all files had the extension .cls.xml, etc.

    Now it’s enough to change the ExpMode parameter to the UDL format in order for everything to work.


    For installation, it is enough to follow 4 simple steps:

    • Download or clone repository
    • Import File - SourceControl.cls.xml in Studio
    • Open the portal, go to Configuration / Additional Settings / Source Control and select Util.SourceControl as the version control class in your area
    • Open a terminal, open your area and run do ##class(Util.SourceControl).Init()

    But what if I want to export to another folder?

    There are several options for this. .. # ExpMode can have values ​​0, 1, 2 for export to .xml, .cls.xml and in UDL formats, respectively. The .. # SourceFolder parameter indicates where to save the files. .. # RefreshTime indicates how many seconds you need to check for new files in a folder to import them.

    In principle, in conjunction with git, this project provides all the necessary functions.


    The next project on the resurrection list was CacheUpdater. Its function can be perfectly understood by example. Let's say you have a GitHub repository and 100,500 servers that use it. This will be a nightmare if you want to change something (you will have to update each server with pens everywhere). CacheUpdater solves this problem just the same - it periodically updates local files by downloading them from GitHub.


    Its installation is a little more complicated:

    • Also download all files
    • Import Task.cls.xml into Studio
    • Open System Operation / Task Manager / New Task
    • Come up with any task name, select the area in which you want to synchronize files, select GitHubUpdater as the type of task, enter the data of the repository and your account on GitHub
    • Click Finish
    • Choose refresh rate

    You are ready for battle, no additional settings need to be made.


    The same project is a fully-fledged system for continuous integration with GitHub.

    Project Installation

    • Just download the Install.cls.xml file (if you want, you can download all the files) and import it into the project

    • Run in terminal ^

                              Set pVars("Namespace") = "{namespace}" 
                              Set pVars("IP") = "{IP}"
                              Do ##class(CacheGitHubCI.Install).setup(.pVars)

      where, namespace is the area where you want to install the project. If it is not, then it will be created automatically;
      IP is an optional parameter of your server (used for webhook).

      For instance,

                              Set pVars("Namespace") = "SAMPLES" 
                              Set pVars("IP") = ""
                              Do ##class(CacheGitHubCI.Install).setup(.pVars)

    Done, enough to test the health. Then, it will be necessary to carry out the same manipulations with creating the Task, as in CacheUpdater. Great, everything works! And, probably, inadvertently a question appeared in your head - “Why do I need CacheGitHubCI if I can use CacheUpdater?”.

    CacheGitHubCI makes it possible to indicate what actions should be performed before and after compilation, to do unit tests. You can configure webhooks so that everything is updated as soon as a new commit appears in the repository and much more. About how to configure all the buns of this system, you can read in the repository itself.


    So far we have only updated 3 repositories. There is something to strive for, the list contains Cache Tort Git , which represents a full-fledged work with git in conjunction with TortoiseGit .

    Also popular now: