Somewhere between the physical and the virtual
More announcements ...
One of the things that we promote as being easy to do and incredibly powerful is the Opalis Quick Integration Kit (QIK) and how it can be used to create your own Integration Packs and compiled .Net code.
Well, this morning I did this for the first time myself. I am very lucky to have the Opalis engineering team to hand, so I sat down with Robert Hearn and Gp De Ciantis and worked my way from dangerous scripting marketing guy to Opalis IP creator in the space of an hour. OK, so this was a fairly straight forward case, but I learnt a lot about the process and wanted to share my experiences. I know a lot of you out there have significant PowerShell and other scripting skills, and I can assure you that they are fully leveragable in the Opalis and Orchestrator solutions!
So, lets take a journey of discovery
Where did we start?
For MMS, I did a SQL Migration demo, where I used Orchestrator to have DPM recover a database from one SQL server to another. The actual DPM commands where executed via a PowerShell script, as this is an action that is not provided for in the DPM IP.
This script was designed to be functional. It had credentials in plain text, and for the demo we simply took a copy of this script, did a search and replace using static string placeholders in the script and then ran it.
Functional, yes. Repeatable, sort of. Maintainable, no.
So, we picked up this script and did a few things:
After testing this in the PowerShell ISE to validate that our changes were functional and the script behaved as expected, we then took the command line and ran it through the QIK CLI.
Step 1 – the Opalis QIK CLI
Once we had the PowerShell script in a state where we could run it with input variables and parameters, we can take that and run it through the QIK CLI to create a .Net DLL that we can invoke directly, or that we can use to create an IP. More on that later.
When you start the QIK CLI, you define the name of the assembly and the file you want to create. You can also reload this file later if you want to modify and repackage.
Then we add in the Commands we want to be available in the assembly. We only have 1, but you can have more than this if you want to compile a lot of script functions together.
On the arguments tab, we take the command line that we used earlier, and use that as the basis for the assembly command. What we then do is take each of the variable inputs of the command line, and make them a Parameter. You can see that each of the input variables in the command line maps to a Parameter below.
This is also where we take care of the password. You can see above that all the inputs are plain text strings, except the Password parameter. This is an Encrypted Text field.
What this means is that when you enter your password in Opalis, all you see are asterisks (******) and unless you do something silly like echo the password, you will never see what the password is anywhere, including the logs and execution results.
And that’s it. We only have 1 command, so we can finish the wizard and our DLL is created. We can now use this in Opalis.
Using the QIK IP, we can invoke this assembly and execute it.
Drag this activity out onto the Opalis palette and we can configure it to point to our new assembly file.
And on the Properties tab of this activity, we can see the Parameters we defined earlier and can fill them out. Not the encrypted text in the Password field.
So we have completed Step 1. We have moved from executing a PowerShell script remotely on the DPM Server, which included plan text credentials, to having a .Net assembly file to trigger the same commands via PowerShell remoting, with encrypted password use.
Now for Step 2 … creating an Integration Pack from this assembly and being able to distribute this functionality across our Opalis environment. To do this, we click the “Build Integration Pack” button at the end of the QIK CLI wizard. Boy, this is hard stuff
Step 2 – Creating an Integration Pack
The first thing we get is an opportunity to name the IP and apply other IP specific information as well as attach a EULA if we desired.
We can also click the Customize Appearance button and choose a better icon.
Click next, and we can see the objects in the Integration Pack. We only compiled one command, so we only see one. But we can add more.
The next step is a critical one. The assembly we created above still executes the PowerShell script we created. One of the benefits of compiling an IP is that we can include the script in the IP and ensure that it is in place for execution.
We give the new IP file a name and we’re done!
We then deployed the IP using the Deployment Manager and the result is that we have a new IP in the Opalis designer.
Because we now have an activity to use, when we drag this out onto the Palette, we do not need to specify the DLL and class, we just need to enter the information.
And there you have it. In less than an hour, we went from an insecure script to a managed Integration Pack. Yes, I had Robert and Gp to help me with the PowerShell code, but given the proliferation of samples and skills out there, the answers were there to be found!
I hope you gain some confidence in giving this a crack yourself. If I as a Marketing Guy can work this through and understand what is going on, you most certainly can too!
Snr. Technical Product Manager
Send me an e-mail Follow me on Twitter Connect with me on LinkedIn