Version Control Example
This topic describes how to use the Gateway Migration Utility (GMU) with a version control tool when developing policies and services for the gateway. The workflow described here can be used with most version control systems. For the examples, Subversion is used.
gateway91
This topic describes how to use the Gateway Migration Utility (GMU) with a version control tool when developing policies and services for the
CA API Gateway
. The workflow described here can be used with most version control systems. For the examples, Subversion is used.You should have good working knowledge of the
CA API Gateway
and the Gateway Migration Utility.Workspace Assumptions
When using the GMU, it is common practice to have your connection arguments in a properties file. This topic assumes that you have an argument properties file containing the properties needed to connect to a Gateway. For example:
host=myGatewayHostusername=myGatewayAdminpassword=7Bywx28jIME.jPobbMOtyGdEcqU3MLp9sAport=8443encryptionPassphrase=WxCXwYpPWf0.CXCLNHYTxJBvUfwtSJkAjw
This topic also assumes that GMU is running on a Unix machine, the following locations:
- GMU scripts are located at~/gmu
- svn repository is located at~/otk_mag
Set Up and Initial Commit
Before continuing, perform an initial check into your version control system. This applies whether you are starting from an existing set of policies and services or from a new Gateway.
Migrate out your Gateway into a versioned folder with this command:
gmu/GatewayMigrationUtility.sh migrateOut -z gateway.properties -folderName / -d otk_temp -f directory --defaultAction NewOrUpdate && (cd otk_temp && tar c .) | (cd otk_mag && tar xf -) && rm -rf otk_temp
This command migrates out to
otk_temp
and then copies the result into otk_mag
. Tip:
This migration/copy is necessary because if you migrate directly into otk_mag
, the GMU first deletes everything from otk_mag
before migrating. This will remove files required by the version control system.Understanding the migration command
gmu/GatewayMigrationUtility.sh migrateOut -z gateway.properties -folderName / -d otk_temp -f directory --defaultAction NewOrUpdate
• This migrates out the root folder ‘/’ into a directory named
otk_temp
(cd otk_temp && tar c .) | (cd otk_mag && tar xf -)
• This copies all files from
otk_temp
to otk_mag
, replacing any existing files. (There are many other ways to copy files, this is just one example.)rm -rf otk_temp
• This removes the
otk_temp
directoryIn the
otk_mag
directory, there are two folders:dependencies
rootFolder
There are also two XML files:
dependencies.xml
mappings.xml
Check this bundle into your version control system.
If you migrate out a full gateway ("--all" parameter is used), there will be many differences with auto generated role IDs. To deal with these, remove the auto generated roles from the export. Entities with secrets also always have a new bundle key when re-exported.
Check Out from Version Control System and Set Up a New Gateway
This assumes starting with a brand new
CA API Gateway
that is licensed and has the Gateway REST Management Service published. For more information, see Publish Internal Service.Check out the bundle from your version control system. Then, import it into your Gateway with this command:
gmu/GatewayMigrationUtility.sh migrateIn -z gmu/local.properties -b otk_mag -r result.xml
This migrates in the bundle located in the folder
otk_mag
and saves the results to result.xml
.Dealing with Environmental Properties
To handle environmental properties that are different across environments, you can templatize the bundle. Properties that may require templatization include: JDBC connection settings, HTTP connection settings, passwords, etc.
- Templatize your bundle with this command:gmu/GatewayMigrationUtility.sh template -b otk_mag -t otk_mag/template.propertiesThis tempatizes the bundle located inotk_magand saves the template properties intemplate.properties.
- Templatizing everything in the bundles includes a large number of properties. To improve usability, reduce the number of templatized properties.
- Open thetemplate.propertiesfile in a text editor.
- Extract only the properties that you want to templatize and place them in a new file. (Remove them fromtemplate.properties.)
For example, if templatizing a single JDBC connection and its secure password, your extracted template properties might look like this:#jdbc_connection OTK_MAGtemplate.jdbc_connection.OTK_MAG.Extension.ConnectionProperties.user.StringValue=OTK_MAGtemplate.jdbc_connection.OTK_MAG.Extension.JdbcUrl=jdbc:mysql://devhost1:3306/otktemplate.jdbc_connection.OTK_MAG.Extension.ConnectionProperties.password.StringValue=myDevPass - With the environmental properties extracted to a separate template file, detemplatize with this command:gmu/GatewayMigrationUtility.sh detemplate -b otk_mag -t otk_mag/template.propertiesThis detemplatizes the bundle located atotk_magwith the template properties in theotk_mag/template.propertiesfile.All properties should now be detemplatized, except the user and host name on the JDBC connection and the bundle key and password value in the secure password.
- To migrate in the bundle from above:gmu/GatewayMigrationUtility.sh migrateIn -z gmu/local.properties -b otk_mag -r result.xml --template otk_mag/environment.propertiesThis migrates in the bundle located in theotk_magdirectory and applies the template properties inotk_mag/environment.properties.
- To test the policies and services, check them out from source control, then import them into the Gateway using the custom environment.properties file:gmu/GatewayMigrationUtility.sh migrateIn -z gmu/local.properties -b otk_mag -r result.xml --template otk_mag/qa_environment.properties
Detemplatizing a Bundle
You can partially detemplatize a bundle with the following script:
#!/bin/bashif [[ -z "$1" || -z "$2" ]] ; thenecho "Need to specify a bundle and template.properties: $( basename $0 ) <bundle> <template.properties>"exit 1elif [ ! -e "$1" ]; thenecho "Bundle does not exist: $1"exit 1elif [ ! -r "$1" ]; thenecho "Cannot read bundle $1"exit 1elif [ ! -e "$2" ]; thenecho "Template properties file does not exist: $2"exit 1elif [ ! -r "$2" ]; thenecho "Cannot read file template properties file $2"exit 1fiscriptDir=$(dirname $0)workingDir="templateWork"mkdir -p ${workingDir}bundle="$1"templateProperties="$2"fullTemplateFile=`mktemp -p ${workingDir} -t fullTemplate.XXXXXXXXXX.properties`propertiesListFile=`mktemp -p ${workingDir} -t propertiesList.XXXXXXXXXX.properties`reducedTemplateFile=`mktemp -p ${workingDir} -t reducedTemplate.XXXXXXXXXX.properties`#templatize the bundle${scriptDir}/GatewayMigrationUtility.sh template -b ${bundle} -t ${fullTemplateFile}#find the list of template properties to leave from the given template properties fileawk '/^[:blank:]*[^#].*=.*$/ {print substr($0, 0, index($0, "=")-1)}' ${templateProperties} > ${propertiesListFile}# remove all the template properties from the full template properties filegrep -v -F -f ${propertiesListFile} ${fullTemplateFile} > ${reducedTemplateFile}#partially detemplatize the bundle${scriptDir}/GatewayMigrationUtility.sh detemplate -b ${bundle} -t ${reducedTemplateFile}
Assuming a script name
templatizeParial.sh
, you run it as follows:gmu/templatizePartial.sh bundle default.properties
This detemplatizes only the properties listed in
default.properties
in the bundle.This script can be used in combination with the
migrateOut
command when migrating out into your svn directory:gmu/GatewayMigrationUtility.sh migrateOut -z gateway.properties -folderName / -d otk_temp -f directory --defaultAction NewOrUpdate && gmu/templatizePartial.sh otk_temp otk_mag/default.properties && (cd otk_temp && tar c .) | (cd otk_mag && tar xf -) && rm -rf otk_temp