New post
Article
· Mar 14, 2016 3m read

Source control and the production class

#Ensemble

When you create an Ensemble production your namespace acquires a new class definition. For example here is what the class that defines the Demo.Loan.BankUSProduction production in the ENSDEMO namespace looks like when opened in Studio:

Class Demo.Loan.BankUSProduction Extends Ens.Production [ ClassType = "", ProcedureBlock ]
{

XData ProductionDefinition
{
<Production Name="Demo.Loan.BankUSProduction" TestingEnabled="true">
  <ActorPoolSize>2</ActorPoolSize>
  <Item Name="Demo.Loan.BankUSTerminalService" ClassName="Demo.Loan.BankUSTerminalService" PoolSize="0" Enabled="true" Foreground="false" InactivityTimeout="0">
  </Item>
  <Item Name="Demo.Loan.WebOperations" ClassName="Demo.Loan.WebOperations" PoolSize="1" Enabled="true" Foreground="false" InactivityTimeout="0">
  </Item>
  <Item Name="Demo.Loan.BankUS" ClassName="Demo.Loan.BankUS" PoolSize="1" Enabled="true" Foreground="false" InactivityTimeout="0">
  </Item>
</Production>
}

ClassMethod Test()
{
    Do ..Start()
    ;
    Set tSC=##class(Ens.Director).CreateBusinessService("Demo.Loan.BankUSTerminalService",.tBusinessService)
    If $$$ISERR(tSC) Do $system.OBJ.DisplayError(tSC) Quit
    For {
        Read !,"amount:name:taxid:nationality>",tInput,! Quit:tInput=""
        Set tSC=tBusinessService.ProcessInput(##class(Ens.StringContainer).%New(tInput),.tOutput)
        If 'tSC Do $system.Status.DisplayError(tSC) Continue
        Write !,tOutput.StringValue
    }
    Set tBusinessService = $$$NULLOREF
    ;
    Do ..Stop()
    Quit
}

}

At the heart of that class is the XData block named ProductionDefinition. The XML within this block records the configuration items that make up the production.

Each item has a name, specifies the name of the class that implements it, and lists the settings for the item.

Since your production definition is a class, it can be versioned in a source control system in the same way as you'd version the classes that implement the production's configuration items.

However, there are a few challenges. I hope this posting will start a useful discussion about them.

The first challenge is that a lot of our interaction with the production class happens through Portal rather than through Studio. And whereas Studio collaborates with source control (e.g. consults your source control class for permission to save an edited production class), Portal ignores source control when updating the production class.

The second challenge is that some configuration item settings need to be specific to the Ensemble instance where the production is being run. For instance, interfaces probably need to talk to different IP addresses when running in your test environment versus when running on your live environment. So if your source code management procedures mean that you export your production class from your test environment and import it into your live environment in order to deploy a new release of your production, you run the risk of making your live instance talk to test instances of your external systems.

How does your Ensemble development team deal with these issues?

Discussion (3)1
Log in or sign up to continue
Ben Spead · Mar 14, 2016

John,

As you are probably aware, the Ensemble Management Portal does enforce source control hooks when editing other Ensemble configuration items, but that does not extend to the Production class currently.  There is a (rather long-standing) Prodlog asking that this be corrected and that the Production class be protected via the Source Control hooks that are active for a given namespace.  The number is 94592 and I suggest that you contact the WRC and ask them to officially log your need for this feature against that Prodlog (other customers are encouraged to do the same if it is something that you need as well).

Until this is available, the best process that I have found for managing Ensemble productions via Source Control is:

  1. Open the class in Studio and check it out
  2. Make your changes via the Ensemble Management Portal
  3. Return to studio and do a "Forced Compile" (which should trigger an exportof  the file)
  4. Check in your change.

This is certainly open to user error, but until the product supports source control hooks in the portal, it is the best hack that I have found for making sure the source of your Production is protected.  You could also create a watchdog task which periodically checks the save timestamp of the Production and compares it to the timestamp on disk to see if perhaps the production has been changed while your export has not - I have not tried this but theoretically it would be a way to provide a level of protection against people forgetting to check in changes. 

To answer your question about environment specific production settings, I would point you to the System Default feature of Ensemble which was designed specifically to meet this need:

http://docs.intersystems.com/ens20152/csp/docbook/DocBook.UI.Page.cls?KE...

Using System Defaults your environment-specific details are no longer stored in your class so you can move the class without having to worry about overriding an IP address, etc.

Hope That Helps!

Ben

1 0
John Murray · Mar 15, 2016

Thanks for the feedback Ben.

I'm familiar with System Defaults, and we actively try and promote their use when we talk to Ensemble users about this issue. However, the way that Portal defaults to filing configuration item settings into the class means that it's all too easy to do this by accident. In contrast, to add/edit a System Defaults type of setting requires significantly more effort within the UI. Surely a better job could be done here?

I expect Prodlog 94592 already has the name of George James Software all over it, as we've been lobbying on this issue since the very beginning. While we wait, we've devised some techniques that allow Deltanji to leverage the OnConfigChange classmethod that a 2012.1+ production class can be given. You can read about them here.

John

0 0