July 6, 2016

One of the common problems in a production environment relies on having a shared connection information between all of the scripts that operate in that environment. In searching for a solution, I developed the following approach for our maintenance scripts written in VBScript.

For all connection information, a common XML file is created that stores all connection information. This file is then protected using the appropriate controls within the operating system. The structure is similar to a App.config for Web.config file for most .Net solutions.

Then, from the VB script, the database connection can be retrieved via the following function:

Function retrieveDBConnection( sPasswordFile, sNodeName )
'parse dbpassword file and get connectivity info
Set objXML = CreateObject("MSXML2.DOMDocument")
objXML.Async = False
objXML.Load(sPasswordFile)
'find root node &lt;appSettings&gt;
Set node = objXML.documentElement.selectSingleNode("/appSettings")
' check to see that the root node was found, if not throw a quit
if node is nothing then
WScript.Quit 1
else
for each xNode in node.childNodes
if xNode.nodename = sNodeName then
Dim atttr
for each attr in xNode.attributes
'cycling through each attribute name, find the 'value' attribute
if attr.name = "value" then
'return the found 'value' attribute
retrieveDBConnection = attr.text
end if
next
end if
next
end if
End Function

May 23, 2012

I wanted an incrementing Assembly version, but I didn’t want to have to do it manually. Some quick Googling and I found this nice solution:

I’ve been using SubWCRev that’s in the TortoiseSvn installation (I think it’s downloadable seperately too).
First i create a “template”-file for the AssemblyInfo.cs called AssemblyInfo.cs.in
This is created as a copy of the exisiting one.
Then replace the parts you want changed with SubWCRev placeholders like this:
[assembly: AssemblyVersion(“1.2.3.$WCREV$”)]
Then create a PreBuildEvent to run SubWCRev with appropriate parameters:
SubWCRev <wcpath> AssemblyInfo.cs.in AssemblyInfo.cs
Done.

September 27, 2011

You have the SDK. You have the JavaDocs. There are samples, but how does it all glue together? This post is all about writing your first UMO custom trigger. These triggers help to automate tasks or enforce business rules within UMO.

What you Need?

A few needed items:

Unica Marketing Operations (UMO) environment

Eclipse IDE for EE

Associated JARs: affinium_plan.jar, log4j.jar

The JARs are best grabbed from the UMO environment.

Start Eclipse & Code

Startup Eclipse and create a new Application Client Project. This project template option is available under the Java EE folder.

Set the JDK to the same level as the web application server that UMO is deployed on. I selected 5.0 for JDK 1.5.

Here I define my AutoReviewerAssignment class. All triggers are required to implement the IProcedure interface.

Unica products use Log4J for all system logging. There are a couple of products in the Unica suite that don’t, but it’s a safe bet that log4j is being used. For UMO, it is. I’m getting the logger and setting it to a static variable. This way I can add my own class’ log entries to the main log file.

The interface defines some standard methods, the first of importance is the initialize() method. This is your time to grab some site specific parameters. In some cases, I’ve grabbed from a standard Java .properties file. But Unica also provides the ability to define these parameters in the actual procedure definition file where the procedure is declared (more on this later).

Finally, there’s the execute method. This is where the action happens and is unique to your own implementation goals.

Configuration Deployment

Once compiled, it’s time to migrate the compiled class file for your procedure. Here’s the steps:

Review the [PLAN_HOME]\conf\plan_config.xml to ascertain the environment’s configuration. We’re looking for the following UAPInitParams: integrationProcedureDefinitionPath and integrationProcedureClasspathURL

integrationProcedureDefinitionPath points to a procedure_plugins.xml file. This file defines the class, including the initialization parameters. Here’s an example:

1:<procedure>

2:<key>POCtest</key>

3:<class-name>com.amberleaf.procedure.POCtest</class-name>

4:<init-parameters>

5:<init-parameter>

6:<param-name>debug</param-name>

7:<param-type>java.lang.Boolean</param-type>

8:<param-value>true</param-value>

9:</init-parameter>

10:</init-parameters>

11:</procedure>

integrationProcedureClasspathURL points to the directory where the resulting class file should be placed

Finally, bounce the web application server so that the new class can be cached

Now that the environment is setup, it’s time to define the actual trigger. This defines when the trigger should actually fire within Unica Marketing Operations. To do this, we go to: Settings > Marketing Operations Settings > Trigger Bindings.

Click ‘Add New Trigger Binding’

Define the trigger with the appropriate attributes:

For example, my trigger would be limited to the ‘Project’ marketing object. The trigger would be limited to the context of ‘People’. Put another way, the trigger would be limited to the ‘People’ tab under the ‘Project’ object. I then further limit the trigger to only execute on the ‘Updated’ event. In summary, the trigger will fire when the ‘People’ tab of a ‘Project’ is ‘Updated’.

And there you have it. You’ve created your first trigger. A special note here. Since we latched on to the log4j logger of Unica’s, we will see our logging entries in the Unica Marketing Operation’s system log. Just be sure to set your log4j logging level appropriately.