Introduction
Did you know that all the objects that exist in a domain are there just because of a single configuration file? Did you know that you can wipe out all the objects by simply deleting the content of this file? Did you know that you can manipulate all the objects using your favorite text editor?
If you answered yes to any of the above questions, you are done and don't need to spend any more time at this article. If not, take a seat, relax, and enjoy these tips as you become a DataPower cheater.
Understanding the case
While booting, DataPower will look for all the .cfg files spread over all the domains. These .cfg files contain instructions on what objects and configuration should be loaded to the memory for execution time. Actually, the only reason why you have the objects in place when you restart your domain or recycle the entire box is because of these .cfg files that are storing details of almost everything for you.
Take a moment to analyze any .cfg file you may have in the default or any other existing domain. Usually they are named after the domain name, so if you have a domain called Sandbox, you will have one config:///Sandbox.cfg file. The .cfg file of the default domain falls into an exception and will be called autoconfig.cfg.
Take a moment there, start reading some lines, you will soon realize that all the objects you have created using any DataPower interface will be there. Created a new Crypto Profile? It will be there. Created a new Deployment Policy? It will also be there. Defined a password for a local user? Nah, that will not be there, and honestly, I don't know where this information is stored. :-)
Usage
I particularly use this a lot. Duplicating, triplicating and sometimes quadruplicating Deployment Policies used to kill me back in the day. That was because I used to do all that using the WebGUI. If you have already done that you know what I am talking about. Imagine a scenario which you need to create one Deployment Policy for each environment, let's say one for UNIT, one for INTG, one for PERF, and one (or more) for PROD. I would imagine you would keep the one for UNIT that you supposedly created first open in one browser tab and visually refer to it when creating the others. That means a lot of eyes work from left to right and MANY clicks to add the Modified Configurations. So after dying a few times, I decided to investigate a less time consuming way to do this, and that was when I had this idea to do this through the .cfg file.
My UNIT deployment policy was the following:
deployment-policy "Service-UNIT-DeploymentPolicy"
modify "*/*/wsm/wsm-endpointrewrite?Name=.*&Property=WSEndpointRemoteRewriteRule/RemoteEndpointHostname&Value=.*" "change" "" "unit-server.datapower.com"
modify "*/*/wsm/wsm-endpointrewrite?Name=.*&Property=WSEndpointRemoteRewriteRule/RemoteEndpointPort&Value=.*" "change" "" "80"
modify "*/*/services/multiprotocol-gateway?Property=DebugMode" "change" "" "off"
modify "*/*/services/ws-proxy?Property=DebugMode" "change" "" "off"
exit
So to duplicate something similar for my INTG environment, I just copied it and pasted it on the line below, changing the parameters pertaining to the new environment, such as name, hostname, port, etc:
deployment-policy "Service-UNIT-DeploymentPolicy"
modify "*/*/wsm/wsm-endpointrewrite?Name=.*&Property=WSEndpointRemoteRewriteRule/RemoteEndpointHostname&Value=.*" "change" "" "unit-server.datapower.com"
modify "*/*/wsm/wsm-endpointrewrite?Name=.*&Property=WSEndpointRemoteRewriteRule/RemoteEndpointPort&Value=.*" "change" "" "80"
modify "*/*/services/multiprotocol-gateway?Property=DebugMode" "change" "" "off"
modify "*/*/services/ws-proxy?Property=DebugMode" "change" "" "off"
exit
deployment-policy "Service-INTG-DeploymentPolicy"
modify "*/*/wsm/wsm-endpointrewrite?Name=.*&Property=WSEndpointRemoteRewriteRule/RemoteEndpointHostname&Value=.*" "change" "" "intg-server.datapower.com"
modify "*/*/wsm/wsm-endpointrewrite?Name=.*&Property=WSEndpointRemoteRewriteRule/RemoteEndpointPort&Value=.*" "change" "" "80"
modify "*/*/services/multiprotocol-gateway?Property=DebugMode" "change" "" "off"
modify "*/*/services/ws-proxy?Property=DebugMode" "change" "" "off"
exit
Once done, it was just a matter of restarting the domain and the Deployment Policies were replicated.
Other related tips...
Use it to find out the right CLI command to perform a specific action
Don't remember exactly the CLI command to create a crypto object? Just go to the .cfg file and try to find a reference for it, when you find it, that is the command you are looking for. That is because the .cfg is nothing more, nothing less than CLI commands grouped in a single place.
Use it to delete a massive amount of objects
For example, you created a bunch of Web Service Proxies or Multi Protocol Gateway. By default, when you create these objects you are rewarded with a lot of child objects that will not go away even after you remove their parents, such as matches, processing actions, slm policies, etc. Good news is that they are named after their parents, so you can sort them out easily and quickly select them for removal.
Changing object names
In general, you cannot change object names in DataPower. Gave it the wrong name? Delete it and recreate it. As an alternative to this, go to the .cfg file and rename it there. Once done, restart the domain and voilà!
Recommendations
- Be careful. Make sure you know what you are doing before playing with this file. Rule of thumb, always have a backup of it in case something goes wrong.
- Some words are reserved, and the default interfaces won't be there to tell you that, so be careful. Rule of thumb, avoid naming objects that can be confused with an existing command, for example when naming an Alias object, use "xmlAlias" instead of only "xml", as it may be parsed incorrectly by the interpreter when loading the objects to the memory.
- And last but not least, BE CAREFUL, not sure if I have already said that.
Conclusion
The possibilities are endless, you can optimize a lot of your time after mastering on this. Duplicating, bulk deletion, searching for commands, are just the obvious things you can do while playing with the .cfg files. The limit here is your imagination, so if you think of something cool that the knowledge present in this article enabled you to do, don't hesitate to share it with us in the comments section below. Happy .cfg'ing!
