Today, UCDT will allow a programmer to build their own provisioning engine. The engine, as noted in a previous post will need to be written in Java and start with defining a class that implements the GenericProvisionInterface class. That class, once linked into the provision.xml file will allow the user of UCDT to build templates and execute them against the target server.
Now, what was missing from the previous post was a detailed discussion about what exactly needed to be setup within the UCDT database to allow all of this to work. As a note, the upcoming UCDT 9.3 will serve to make all of what you will read here mostly obsolete. However, to fully understand the inner workings of UCDT it is best that a programmer understand these things about provisioning engine integration.
First, do recall that there is a concept of UCProduct and UCProductVersion. These are found both in the provision.xml file and in the UCSYSTEM database table. Within the provision.xml file they are found in any of the lines:
Now, what was missing from the previous post was a detailed discussion about what exactly needed to be setup within the UCDT database to allow all of this to work. As a note, the upcoming UCDT 9.3 will serve to make all of what you will read here mostly obsolete. However, to fully understand the inner workings of UCDT it is best that a programmer understand these things about provisioning engine integration.
First, do recall that there is a concept of UCProduct and UCProductVersion. These are found both in the provision.xml file and in the UCSYSTEM database table. Within the provision.xml file they are found in any of the lines:
<provision provisionProduct="ThirdParty" provisionProductVersion="LDAP" provisionClass="ldap.LDAPProvision"/>
All of the provisioning engines you create must be defined within "ThirdParty" as the Product with the ProductVersion being something meaningful to you and your intended audience. For example, above is how an LDAP provisioning engine might appear. And, the last item there is of course the name of the java class that extends the class you created to implement GenericProvisionInterface.
Within UCSYSTEM you will see that there are three columns, a unique ID, the UCPRODUCT and the VERSION. The unique ID should just be the next sequential number from a SELECT MAX on that tables SYSTEM_ID column. The UCPRODUCT must be the "ThirdParty", exactly as you have it in your provision.xml's provisionProduct field. And, the VERSION must be the same value that you have in your provision.xml's provisionProductVersion field.
The provision.xml snippet and the screen capture above align with each other as you can see the provision.xml entry matched on like 26 of the UCSYSTEM table.
OK, That is the first part of getting a provisioning engine working. The next part is just as easy, but, it might seem hard at first glance. Let's first break it down by the work steps, then let's go into each one individually, then let's recap those items:
In order to make use of a provisioning engine, you must create templates that use them, a script that organizes those templates and a superscript that coordinates multiple scripts. Do recall that a template is the lowest level in the hierarchy of the system. The template might generate hunderds or thousands of commands to a UC Server, or it might only generate one or two commands, or maybe no commands at all. The next level up is the Script. The Script will control the execute order of several templates. And, like a script running multiple templates, a SuperScript will coordinate the execution of multiple Scripts.
So, our first task is that we have to create a SuperScript, a Script and any Templates that will be running.
Next, we need to associate a server device to the enterprise for our target server type.
Finally, we need to added data for our enterprise/branch.
At this point we can run provisioning. And, please keep in mind that the term 'provisioning' is a bit missleading here as the actual function of the provisioning engine might have absolutely nothing to do with provisioning. For example, we might be scraping all the data out of LDAP to be transferred to a 3rd party database. Or, we might be executing a process to perform tests against deployment phones - ensuring that they are operational.
Creating the SuperScript is easy, we simply need to go to the Template Builder's user interface and select SuperScript to add in the SuperScript.
Adding the templates is easy, too, we can use the Template Builder UI for that.
Adding the Script is the tricky part (only until UCDT 9.3 is delivered), and to do that is not too bad. Here's what you need to do.
Within the database locate the SCRIPT table. You will find a table that has 6 columns: SCRIPT_ID, AUTHOR, CREATED_DATE, FK_SYSTEM, SCRIPT_VERSION and SCRIPT_NAME.
You will make one or more entries in this table to define your script(s). SCRIPT_ID should be set to the MAX(SCRIPT_ID) + 1 so that it is the next sequential value for the existing values in that table.
AUTHOR can just be set to '1', for Superadmin, unless you want to tie it to another specific user ID.
CREATED_DATE can be something easy like "2013-11-01 08:00:00", but you can feel free to set it to any date and time you desire.
FK_SYSTEM will be the SYSTEM_ID from the UCSYSTEM table for the provisioning engine server you want this to apply against. Be aware that the SERVERS table will define actual servers, the UCSYSTEM table defines a class of servers, like LDAP servers.
SCRIPT_VERSION must match the version you supplied in the provision.xml file and the version identified in the UCSYSTEM table.
SCRIPT_NAME is the name you would like to use so that you and your users recognize it.
Here is a sample of my Script table, notice that my LDAP's entry is tied to FK_SYSTEM '26' and that lines up nicely with the example up above.
Now, with that built we can use the UCDT user inteface to add templates to it and to add it to a SuperScript.
Here is an example SuperScript that uses my LDAP class:
In the example above I created a SuperScript titled ProvisionLDAP and within that I added two scripts, the first script is titled "AddNewEmployee" and the other is "Customer.EnableForJabber". The "AddNewEmployee" script is simply named and is only a script that contains one template to read data from LDAP. The second template "Customer.EnableForJabber" is a script that also only contains one template and that template will connect to the appropriate CUCM and update the enduser appropriately.
Here is that template for reading data from LDAP:
You might look at that template and wonder where all the specific's are for reading LDAP. Well, all the specifics are within the provision engine I wrote. So, the way it works is that UCDT will pass to my provision engine the LDAP server credentials and basedn so that the Java code used can access the AD data. The "Values" you see in the template above will be used as a filter to read data from LDAP and then pass that back for use in a latter template.
Keep in mind that in the template you see "$VAR_USERNAME_VAR" and also "$VAR_ENABLEMENT_VAR", those are variables that will be set within the UCDT datapool prior to actually kicking the SuperScript containing this template off for execution.
Now, One final item to keep in mind is a table that maps templates to their respective script owner, and yes, a template can belong to one and only one script. However, a script may belong to many SuperScripts (in case you were wondering). The table that contains the mapping of templates to scripts is the TEMPLATE table itself. Here are the columns within that table:
template_id numeric(10,0) NOT NULL,
name character varying(150) NOT NULL,
description character varying(150) NOT NULL,
pos_in_script numeric(10,0) NOT NULL,
body text NOT NULL,
fk_script numeric(10,0) NOT NULL,
include_in_xls numeric(10,0) DEFAULT NULL::numeric,
reference_template numeric(10,0) DEFAULT NULL::numeric,
fk_template_type numeric(10,0) DEFAULT NULL::numeric,
dynamic_templating numeric(10,0) DEFAULT (0)::numeric,
tagged_templates text,
axis numeric(10,0) NOT NULL DEFAULT (0)::numeric,
The two columns we care about here are the FK_SCRIPT column and the POS_IN_SCRIPT. The FK_SCRIPT must be the SCRIPT_ID from the SCRIPT table for our script and the POS_IN_SCRIPT is any numeric value. The numeric value will be sorted ascending to provide the proper order of execution of the templates within the script.
This entire process is important to understand, so, it is good that you have read this far. But, when UCDT 9.3 is released you will not need to specifically set the FK_SCRIPT and POS_IN_SCRIPT, nor will you have to insert rows, manually, into the SCRIPT table. Personally, I cannot wait until this is released!
Now that you have setup these tables you are ready to provision, or, rather, you are ready to test your provision engine code :)
Putting it all together, now.
You already wrote your provision engine code, and now you want to test it. So, you need to stop tomcat and deploy your new provision code to:
C:\Program Files\Cisco Systems\UCDT\Tomcat\webapps\UCSPT-CE\WEB-INF\classes
You need to update provision.xml so that your server type can be provisioned with the code you deployed.
You need to update UCSYSTEM to add a single entry for this new provision engine under the product heading of "ThirdParty".
You need to manually update the database to add an entry to the SCRIPT table and you need to use the UCDT Template Builder UI to add a SuperScript to include this new Script and you need to use the Template Builder UI to create one or more templates to include in the Script. Use the database editor PGAdminIII to manually alter the TEMPLATE table data to move your templates in the proper order if they need to be reordered.
Now, with all this set you are in operations mode. You can create a branch with data, make sure you assigned a server to your branch (ThirdParty only pre-UCDT 9.3) and then you can go to the provision page to test, test, test.
Well, I hope this helps you. In my next post I will discuss testing of your provision engine code.
Cheers!
No comments:
Post a Comment