We have four environments in which we develop and deploy our Applinx applications: dev, staging, QA and production. Once an application moves from dev to staging, it remains as a gxz file repository.
What I’d like to do is to be able to accommodate configuring the Applinx application per environment. However I don’t see a way for Applinx to reference an external file to load any configurations. I’ve considered using a database to store configurations. However Applinx really only needs to load the parameters for a particular environment once rather than making a database connection for parameters at every request.
I’m looking for the best way or the recommended way to properly provide external configuration parameters to an Applinx application so the gxz repository can be the same file for any environment.
ApplinX application export file (gxar) holds two types of configurations:
1 - Application configuration (gxconfig.xml) – this holds: The host properties (address, port, type, protocol, security etc), type and location of the repository, host windows configuration, keyboard mappings, and basically everything that you can configure by right click → properties on an ApplinX Application.
2 - Application entities (gxz) a zip file that contains the application repository with its entities and their relations (Screens, Screen Groups, Path/Flow Procedures, Connection Pool, Connection Info Set etc…).
Now the question is what kind of properties would you like to change in production?
1 - If it’s related to the Application configuration, this can be done by keeping the gxconfig.xml for each environment by moving only the gxz (repository) between environments and not the gxar which contains both.
2 - If it’s related to changes in the entities, you must have the repository read-write by converting it to a database based repository and currently there is no partial opened repository and/or external properties functionality.
But there are workarounds to do this task. For example if you have a different connection pool settings for production and you would like to keep them after importing a new gxz from dev, you can export these specific entities from production (before importing the new gxz from dev) and after importing the new gxz from dev you should import the prod specific entities to override the dev entities.
Assaf - #2 is the typical case that I encounter. Environments to connect to are different between dev/test/prod - different LPARs, different CICS regions, different userid/passwords, different CICS transactions, etc - all information that is usually contained in the Connection Information Sets. Modifying the read-only repository as you suggest requires the deployment administrator open the repository for edit, introducing the possibility of side effects that are hard to trace, verify and guarantee application integrity to an auditor’s satisfaction.
An external configuration file to be applied to the connection information would alleviate this concern.
I concur with Douglas. The differences between environments could require changes to the Connection Information Sets. For our organization, any changes need to tested prior to deployment.
Douglas- how do I get access to the Brainstorm site?
To handle the use case you describe you can have 4 Connection Information Set entities (dev, staging, QA and production) and in the Connection Pool entity you will decide which one to use in each stage. Before going to the next stage you can change the info set to the next one, and only after checking that everything works you can export the application to the next stage server.
Unfortunately this approach won’t work for our organization as once the application is exported from staging (build) then it’s not allowed to be edited again thru QA and to production.
We need to control the application to use specific connection pools (also CICS region and/or LUs) per each environment. The only requirement is that the environment parameters be set using a file. It could be an XML or .ini type file; anything should be OK as it just needs to be external so the same gxz is used from staging onwards.
Just the LU portion. Once connected we then have to send a command to the mainframe to use a particular CICS region. The command changes from staging to QA to prod.
To confirm that I understand, for changing the CICS region you should enter different data in a screen after you created the session (using a path procedure I assume)?
And how do you set the LU? Also using a screen or as a parameter to the session using the connection information set DeviceName property?
Regarding the info set external file location, should it be the same relative location in each server or in each stage the server should configure different location?
CICS region is not host:port nor LU. It is an application session (TP monitor) on the mainframe. Production, test, qa, dev are separate CICS regions within the mainframe (host:port) LPAR. The CICS region selected is an input to the path procedure used to log in to the application.
Typically the user id and password are different for each environment also, so these are included in the Connection Information Sets along with the CICS region name.
Is there a way to merge two GXZ files into one at the command line? That would facilitate automating a build process to produce builds for each environment.
Unfortunately, we don’t have a utility the merges two GXZ file into one. However, you can use the ApplinX different Batch file utilities to create a Job of your own. These utilities will allow you to import/export GXAR files as you see fit, from the command line.
I believe you can use them to create the desired result.
You can find the in the utilities folder under the ApplinX installation directory. To lean more about them and the parameters they require, open the ApplinX documentation overview page and click the Batch Automation Utilities link at the bottom of the Administration section.
Hope this helps,
Let me know if you need further help,
Ohad
I have solved this problem at a few customer sites by letting the application call an external localhost web service which returns the requested environment information - notably the name of the current environment (development, test or production).
The web service server application that provides this information was developed as a separate ApplinX application “GetEnv”.
In the development environment I develop then not only the acutal application but also three GetEnv applications - one for each target environment.
Typically the GetEnv applications needs only to be deployed once to each target environment - as there are no changes to it over time.
So in production for example you will have two gxz-based ApplinX applications - one that actually does the work and one (GetEnv) that tells the other where it is running.
There appears to be a problem in Tomcat that keeps ApplinX from calling a web service on the same Tomcat that it itself is running in. Therefore you can no longer use the “localhost GetEnv” web service approach.
Only idea left is to keep the information in SessionData or connection information sets. Here I use connection information sets:
Keep your application in databases in all environments. See the documentation on how to change the repository from a gxar file to a database.
To migrate a changed application to the next environment you need to use the designer (which is not well thought of in production environments…)
In the source environment:
1 - switch the connection pools to manual to avoid them inadvertently starting when you import the application in the target environment.
2 - switch the connection information sets definition in the connection pools to empty ones.
3 - export the application to a gxz file.
4 - switch the connection pool back to automatic (or whatever) and set the connection information set definition back.
In the target environment:
1 - Alert client application users and shut down client applications.
2 - Import the gxz file with the changed application.
3 - Use the designer to change the connection pool to automatic (or whatever) and to use the connection information set that pertains to the target environment.
4 - Also in the designer - re-load the application.
5- Start the client applications.