Caché or Ensemble
A single Deltanji instance can manage remote code located on more than one Caché or Ensemble node by the use of InterSystems' Enterprise Cache Protocol (ECP). Deltanji itself can be installed on one of the nodes where managed code is located, or you can set up a dedicated node to host Deltanji. Either way, the node hosting Deltanji lies at the centre of the ECP network used by Deltanji. Outbound ECP connections from the Deltanji-hosting node link to each of the other nodes where code is to be managed. In InterSystems terminology the Deltanji node is an ECP application server and the other nodes are ECP data servers. Each of those nodes must also have an ECP connection to the Deltanji node, i.e. they are also ECP application servers connecting to the Deltanji node as their ECP data server. Thus a 'hub-and-spokes' topology is created, with a pair of links on each spoke to provide bidirectional connectivity.
Note: Some InterSystems license keys do not include ECP. On version 2010.1 or later the expression $SYSTEM.License.NetworkEnabled() returns 1 if ECP is licensed. Alternatively, consult your InterSystems account manager.
The following instructions assume all the nodes are hosted on the same type of operating system (i.e. all Windows, or all UNIX/Linux, or all OpenVMS). Consult Deltanji Support for additional guidance if you need to deploy Deltanji in a heterogeneous environment.
1. Install Deltanji on its node using other sections of this book.
- When installing program files, if possible place them on a network share that all nodes in your Deltanji network can access using the same name. For example, if your nodes run on Windows share the directory where you place the unpacked software kit, e.g. as \\deltanjihost\deltanjikit.
- When entering the installation directory path as you run the installation script, specify the network share name rather than the local directory path. Note that if your host OS is Windows the Caché or Ensemble service needs access to the share, i.e. it cannot run under the LocalSystem account.
2. Enable the %Service_ECP service on all nodes, so they can all act as ECP data servers. Make sure that the Deltanji node will be able to accept enough concurrent incoming ECP connections. If necessary, increase the parameter that affects this limit. For added security the ECP service can be configured only to accept incoming connections from specific IP addresses or hostnames. If you do this, make sure that the connections detailed in subsequent steps will be permitted.
3. On each node apart from the one hosting Deltanji, define the following using Management Portal:
- An ECP connection to the Deltanji node. For consistency use the same connection name on each node. The suggested name is DELTANJI.
- A remote database definition named DELTANJI using the ECP connection defined in the previous step to access to the Deltanji database (normally named DELTANJI) on the Deltanji node.
- A security resource with a name matching the one managing the remote database, e.g. %DB_DELTANJI. For ease of initial setup, grant Read and Write public privileges on the new security resource. You may subsequently decide to tighten up security by removing the public Write privileges and giving it only to Deltanji users. Retain the public Read privilege so that other users don't encounter errors as a consequence of the mappings (global, routine and package) that may cause their processes to read this database.
- A local database called DELTANJI-LOCAL. Opt to create a new security resource to control access to the database. Accept the default name for this security resource (%DB_DELTANJI-LOCAL). For ease of initial setup, grant Read and Write public privileges on the new security resource. You may subsequently decide to tighten up security by removing the public Write privileges and giving it only to Deltanji users. Retain the public Read privilege so that other users don't encounter errors as a consequence of the mappings (global, routine and package) that may cause their processes to read this database.
- A namespace called DELTANJI-LOCAL that uses the DELTANJI-LOCAL database as its default database for globals and routines. On Caché, clear the checkbox that would otherwise create a default web application for the namespace. On platforms where Deltanji will be controlling Ensemble-enabled (a.k.a. production-enabled) local namespaces the DELTANJI-LOCAL namespace must itself be Ensemble-enabled, and thus will also be configured with a default web application.
- A namespace that uses the DELTANJI remote database as its default database for globals and uses the DELTANJI-LOCAL database as its default for routines. The namespace name must match the one on the Deltanji node, which is normally called DELTANJI. Where possible, clear the checkbox that would otherwise create a default web application for the namespace. On Ensemble 2017.1 or later, opt not to Ensemble-enable (a.k.a. production-enable) the namespace and not to create a default web application. If you don't have the option to prevent the namespace being Ensemble-enabled, point it initially at the DELTANJI-LOCAL database both for globals and for routines. Then after the namespace has been created edit its definition to use the DELTANJI remote database for globals. This sequence avoids a situation where the creation of this DELTANJI namespace could inappropriately upgrade the Ensemble components within the remote DELTANJI database.
- The following mappings on the %ALL pseudo-namespace:
- Global %gjtask to the DELTANJI-LOCAL database.
- Globals %vc.Stud* to the DELTANJI-LOCAL database.
- Globals %vc* to the DELTANJI database (remote).
- Routines %vc* to the DELTANJI-LOCAL database.
- Package VCmStudio to the DELTANJI-LOCAL database.
4. On the Deltanji node, export the routines %vc*.INT from the DELTANJI namespace. Then import them into the just-created DELTANJI-LOCAL namespace on each of the other nodes. Compilation errors during import can be ignored.
5. In the DELTANJI-LOCAL namespace in a terminal session in each of those nodes, run
d Cache5^%vcins() When prompted, confirm the loading of the classes, templates and add-ins.
6. In the DELTANJI-LOCAL namespace start the Deltanji task server process using the command
d fast1^%vczn and also add code into SYSTEM^%ZSTART in the %SYS namespace (or into the ZMIRROR
routine if you are using InterSystems mirroring) so that fast1^%vczn is run in the DELTANJI-LOCAL namespace whenever the instance
is started. For example:
s $et="i '$es d $zu(9,"""",""SYSTEM^%ZSTART error: ""_$ze) s $ec="""""
7. On the Deltanji node, define an ECP connection to each of the other nodes.
8. On the Deltanji node, creating a security resource whose name matches that which manages the DELTANJI-LOCAL databases on the nodes Deltanji will manage (i.e. %DB_DELTANJI-LOCAL). For ease of initial setup, grant Read and Write public privileges on the new security resource. You may subsequently decide to tighten up security by removing the public Write privileges and giving it only to Deltanji users. Retain the public Read privilege so that other users don't encounter errors as a consequence of the mappings (global, routine and package) that may cause their processes to read this database.
Multi-server configurations are not currently supported on GT.M.