- Why don't you hardcode the values in script for TARGET & APPLICATION, as you do not want the other user could not set values for these parameters.
- Another workaround, create .csv file & put the values for the TARGET & APPLICATION parameters.
In Script read vaues from this file. whenever you want to change values for the JOB, just mae changes in .csv file.
Well, maybe I didn't explain correctly the problem.
The nsh script is calling BMA for installing applications (APPLICATION parameter) in different environments (TARGET parameter) with especific versions (REV parameter). So, I want to create, from only one script, one job for application A in environment TEST, where the user can select the REVISION of the application. Another one for the same application in environment PRE-PRODUCTION, another one for application B in environment TEST, etc. I mean, the script is always the same, the parameters are the three, but I willl allow the user only to change the REVISION of the application to install.
So, I cannot hardcode anything, and, if I have 200 applications, I will need 400 jobs (2 per application, one for TEST, and one for PRE-PRODUCTION). The 400 hundred jobs are predefined in both TARGET and APPLICATION, the only parameter to be modified by the user is REV. I want the 400 hundred jobs to be based in the nsh script (that way, if I change the way BBSA call BMA, I have to change only one script, instead of 400).
The reason for needing what I have explained is that I will have different roles with permissions for executing specific jobs. That means that there will be a development team that will have permissions for application A and B, while another team will have permissions for application C and D, etc. This is the reason why I cannot allow the user to change TARGET and APPLICATION, and I need all the jobs precreated.
1 of 1 people found this helpful
Perhaps, you can use Property Classes and Property Instances to achieve this.
You can create a Custom Property Class in the property dictionary called APPLICATIONS. Create three custom properties in the APPLICATIONS class
I am using _ in front of each parameter because it keeps all the custom properties you create at one place at the top of the properties list. It makes it easy for you to trace.
After you create the properties, then you create Sub property classes under APPLICATIONS class. One sub property class for each application. I.e you will have to create 200 classes. APP1, APP2...APP200.
Next step, is to create two property instances under each sub-class i.e.APP1 > TEST; APP1 > PREPROD
Then you can set the property values for each instance and make them editable or uneditable as required.
After you setup the above structure, then write a nsh script that uses blcli calls which read values from property instances of specified properties. The only input this script would need is the either the sub-class or the property instance of the sub-class. One script will suffice. Then proceed to create as many jobs you want with that script.
During run time, user will have two tasks:
1. set the value of the editable field in the property instance to which he has access
2. Execute the job
If you haven't worked with property classes before, then the content is available on page#139 in BMC BladeLogic User Guide from BSA Version 8.1
i would also look at how much can be derived automatically. the environment - TEST or PROD - can that be set on the target server or object? what about the other parameters ? do you have to use a nsh script job for this ? what is the script actually doing that it needs nsh ? can the TARGET be derived from the actual target device the job runs against ? etc etc...
The integration with BMA (AKA BARA) implies that the target is allways the same server (the BMA console). There is no connection from BBSA to the different application server environments. You execute the scripts in the RSCD installed in the BMA console that executes the cli for BMA operations. So, I cannot derive anything from the target agent, as it's always the same, no matter if the operations is for DEV, PRE, PROD or whatever environment.
The nsh script is what BMC proposed in the initial implementation. I guess it's the easiest way for executing BMA cli. The script involves a set of actions:
1.- Export configurations and application ear from a version repository (CVS, SVN or whatever you may use)
2.- BMA CLI execution with the previous configurations and application ear. The BMA execution connects to the application servers via SOAP (no BBSA technology is used). The application server it connects to, and the application and version it installs is currently based in the 3 parameters I have explained.
3.- Commit some resulting reports to the version repository.
I was thinking on moving the script to BLPackage (for taking advantage of local properties), but maybe it is a bit artificial as at the end everything will be external commands.
Naveen Anne, I'm only missing one point in your proposed solution:
- I create the estructure of properties
- I will create the blcli for retrieving the info from one instance in this estructure
- I will create the 400 jobs.
- I need some reference for telling the blcli what instance I'm looking for. Each job will retrieve the value from a different instance, so I guess at the end I will need some parameter in the job that points to the instance it needs. So, again, what property in what class I can use for storing the reference to the instance? The Users Guide (pg #140) says that
"You can use parameters and properties in BLPackages, component templates, configuration files and extended objects", but it doesn't say anything about nsh script Jobs. It seems that with a BLPackage you can use a local property where you can reference to the instance you are looking for, but I still don't know where to put this reference in a NSH Script Job.
You can make that a parameter in the script and provide the value of the instance as input to the parameter. That is what I mentioned above that the script will need one input which is the instance of the property class.
The user guide is correct. NSH Script job can't map to property classes like blpackages do. You can only read the values of property classes in a script using blcli calls.
So I come back to my original problem. I cannot have several jobs with different Required and Non editable parameters, created from a single script. At least I don't know how to do that (see the initial post).
are you really stuck w/ the current BMA script ? it seems to me it would make more sense to have the script target the actual target server object (unless it's using an AMO ?) and pass the bma server as a parameter. the script is running in nsh so it can access whatever.
if there is no way to auto-derive some or all of the parameters you need then you will have to create one script job per target/config.
The way BMA works is executing CLI commands from the BMA server itselft. You cannot execute jobs directly to the WAS nodes.
One workaround for what I need is the following:
1.- Change for some minutes the NSH Script with the 3 parameters to be editables (ALL OF THEM)
2.- Create from this NSH Script all the NSH script jobs you need, changing in the "Step 3 of 7" the values of the 3 parameters for the job.
3.- Once created all the jobs, change again the NSH Script for having the last 2 parameters as NO editables.
The problem of this approach is:
1.- For the minutes that you change the NSH Script for having all the parameters editable, any previous NSH script job will be editable. A user may change these parameters on his jobs. I could temporarily restrict the access to the console, but, it seems to be too restrictive only for adding a job.
2.- If, at any point, the administrator doesn't follow correctly the steps, it may lead to problematic situations. For instance, if you create a job (let's say job1) without changing to editable the parameters (but changing their values), and then you create another job (let's say job2) without changing to editable the parameters (but changing their values), then you will have both jobs with exactly the same parameters (the ones you added for job2).