First, a bit of trivia
Since version 8.1 or so, BladeLogic provides Web Services, which is quite handy for anyone planing to build a user front end in the form of a portal.
In the old days you would have had to use blcli to interface with the BladeLogic AppServer and in the even older days (before blcli_execute was introduced) you would probably would have ended up building "Complex Commands" as the amount of released commands was fairly small and almost anything more advanced than basic interrogation would have required to use unreleased BLCLI commands which inevitably meant writing a Complex Command. (... Or using Jython, but that's another story and I've never really succeeded in convincing SysAdmins to adopt Jython.)
So are Complex Commands another slightly old duck? Well, yes and no: I think Web Services might give them another youth.
... And you'll soon find out the beauty of Complex Commands: they are rocket fast. Combined to Web Services it gets even better, especially when the authentication token is being reused.
When a Customer of mine asked me to interface BladeLogic with an end-user portal they have developed, I came up with this idea of building a set of complex commands in order to be able to fire various types of Jobs in a consistent manner. I already had done this in the past without Web Services so I already had put some thinking in how this should be done:
- For scalability, robustness and ease of use, every object involved in a particular Job execution that carries Job execution context items should be created on the fly and only used once.
- Because the user sitting behind the portal has no visibility of the content he is going to run, the "Catalog" of possible Jobs shall sit in a specific object tree.
- Jobs should be fired in asynchronous manner (no "execute and wait" otherwise the portal is going to be really slow and user unfriendly)
- Every Job execution shall have an unique identifier which will make it easy to retrieve the execution logs in a second phase.
The following screenshot gives an overview of the folder structure capable of supporting the Complex Command library:
Image 1: Sample folder structure
Note that the screenshot represents only the Job workspace but the Component Template and Depot workspace would have a similar structure. In this example "/3 - Catalogue/Portal" would contain the models whereas "/5 - Execution/Portal" would contain all objects dynamically created for each execution of a Job. Every Job that runs through the Complex Commands will result in a folder structure containing copies of the Action Job model and
The Complex Command Library
The set of Complex Commands I wrote to expose macroscopic and repeatable actions to the BladeLogic Web Services is capable of executing the following types of Jobs in a standardized way:
- NSHScriptJobs with up to 5 parameters to be positioned at execution time
- BLPackage DeployJobs with up to 5 BLPackage Properties to be positioned at execution time
- Component based AuditJobs (without synchronization)
- ComplianceJobs with auto-remediation (experimental)
In addition there are some utilities that are either used by the Job launcher commands or that can be used to perform additional operations based on the unique Id it got from the Portal, such as:
- Cancel the Job
- Move and rename the logs
The Complex Command library and its documentation are attached below. Note that it's been developed and tested on BladeLogic 8.2.03 and 8.2.04 environments. As long as the BLCLI Name Spaces and Commands remain unchanged this should work properly.
Dealing with notifications and Job execution logs
The next step of course is to keep track of what is going on, get the final JobRun status and eventually retrieve the execution logs. The solution has a built in mechanism that will essentially take whatever Job is put in the "/3 - Catalogue/Portal/_Tools" folder and append it to the Action Job in wrapper BatchJob. In the example illustrated above, the "Portal_POST_end_of_JobRun" Job would be responsible to post a end status notification to the portal's web services (hence the POST), retrieve and format the Job logs and copy them to the portal and finally notify that the logs are available. One could do it differently, like for example posting progression information, or just post a synthetic Boolean status by server, or whatever else is required.
How do I get this working?
Essentially the attached XML file is something that can just be copied in the ~bladmin/server_xml/cli folder of the AppServer running Web Services to enable the additional commands. (don't forget to restart at least the instance running the Web Services to be able to use the commands) Off course the file can also be placed in the ~bladmin/xml/cli folder which will allow the use of the commands with standard BLCLI calls. (no AppServer restart required in this case) A quick read of the documentation provided will do the rest.