In this HowTo, we will use a GT4/MDS4 Trigger as a way to monitor resource information from another GT4 service. We will go step-by-step from start to finish. The current GT 4.1 documentation serves as a reference, but for those of you who would like to get something working without going through all of the documentation, this document will be a good start for you.

We will be writing a simple trigger from scratch, and setting it up completely. To get the basic idea of how this is done, we will use elements available in the default GT4 installation to show you how to use triggers.

1. Prerequisites

GT 4.1 installation. (including Java WS Core and WS MDS Aggregator Framework)
PBS installation. PBS should be properly configured for your GT4 installation. Be sure to enable PBS support when compiling GT4 (./configure --prefix=your-install-location --enable-wsgram-pbs)

2. Step 1 - Set up the GT4 environment

Install:
Install a recent version of GT 4.1.
Apply recent patches if necessary, and/or use a CVS install.
Keep the following in mind:
- More recent versions and installs provide better functionality and are thus recommended.
- If you're new to using GT4, you may wish to follow the GT 4.1.0 Quickstart.
- In this tutorial, we are using a local GT4.1 install and we will be accessing an external cluster running GT4 with PBS. If you do not have PBS installed, you'll want to gain access to a cluster running GT4 with PBS. If you have no access to PBS, consider using Fork instead.
Login:
Login to whatever machine you'll be using and set your $GLOBUS_LOCATION environment variable:
```
setenv GLOBUS_LOCATION /your-install-location/
```
or (depending on your system)
```
export GLOBUS_LOCATION="/your-install-location"
```

Set up security:

source $GLOBUS_LOCATION/etc/globus-user-env.csh
$GLOBUS_LOCATION/bin/grid-proxy-init -verify -debug

Again if this is new to you, please refer to the GT 4.1.0 Quickstart.

Test access:

Test your access to the cluster running PBS.

We can use wsrf-query to poll the DefaultIndexService running on the PBS cluster. Here is a sample query along with sample output:

$GLOBUS_LOCATION/bin/wsrf-query -s https://cluster-location-with-pbs:8443/wsrf/services/DefaultIndexService
"//*/glue:GLUECE//glue:ComputingElement[glue:Info/@glue:LRMSType='PBS' and glue:State/@glue:FreeCPUs>0]"

	Important
	Be sure the above query is all on one line.

The following output has been formatted for clarity.

<ns1:ComputingElement ns1:Name="normal" ns1:UniqueID="normal" 
    xmlns:ns1="http://mds.globus.org/glue/ce/1.1">
    <ns1:Info ns1:GRAMVersion="4.0.3" 
        ns1:LRMSType="PBS" 
        ns1:LRMSVersion="2.1.2"
        ns1:TotalCPUs="96"/>
    <ns1:State ns1:EstimatedResponseTime="0" 
        ns1:FreeCPUs="82" 
        ns1:RunningJobs="2" 
        ns1:Status="enabled" 
        ns1:TotalJobs="2" 
        ns1:WaitingJobs="0" 
        ns1:WorstResponseTime="0"/>
    <ns1:Policy ns1:MaxCPUTime="-1" 
        ns1:MaxRunningJobs="-1" 
        ns1:MaxTotalJobs="-1" 
        ns1:MaxWallClockTime="2880" 
        ns1:Priority="0"/>
</ns1:ComputingElement>

What we've done here is queried the DefaultIndexService on a GT4 deployment which has collected PBS cluster information, and here we can see the results of that query. In this HowTo, the relevant resource information will be the "FreeCPUs" (in bold).

3. Step 2 - Write the trigger configuration file

Overview:
Let's talk about what we will be doing. We will be using a local GT4 install to monitor a cluster running GT4 with PBS. The above query showed us that there are some resources that we can track using our local trigger service. We will set up a trigger to monitor FreeCPUs on the cluster, and to log this information at regular intervals.

Write the configuration file::

Create the configuration file: $GLOBUS_LOCATION/etc/globus_wsrf_mds_trigger/our-simple-trigger-config.xml.

You can copy the contents of the following XML (and be sure to change the elements in bold to your particular setup):

<?xml version="1.0" encoding="UTF-8" ?>
<ServiceGroupRegistrations
    xmlns="http://mds.globus.org/servicegroup/client"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
    xmlns:agg="http://mds.globus.org/aggregator/types">
    <defaultServiceGroupEPR>
        <wsa:Address>
            https://your-install-location:8081/wsrf/services/DefaultTriggerService
        </wsa:Address>
    </defaultServiceGroupEPR>
    <ServiceGroupRegistrationParameters
        xmlns="http://mds.globus.org/servicegroup/client"
        xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
        xmlns:agg="http://mds.globus.org/aggregator/types"
        xmlns:trigger="http://mds.globus.org/2004/08/trigger/types">
        <RegistrantEPR
            xmlns:gram="http://www.globus.org/namespaces/2004/10/gram/job"
            xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">
            <wsa:Address>
                https://cluster-location-with-pbs:8443/wsrf/services/ManagedJobFactoryService
            </wsa:Address>
            <wsa:ReferenceProperties>
                <gram:ResourceID>PBS</gram:ResourceID>
            </wsa:ReferenceProperties>
        </RegistrantEPR>
        <RefreshIntervalSecs>600</RefreshIntervalSecs>
        <Content xsi:type="agg:AggregatorContent"
            xmlns:agg="http://mds.globus.org/aggregator/types">
            <agg:AggregatorConfig xsi:type="agg:AggregatorConfig">
                <agg:GetResourcePropertyPollType
                    xmlns:glue="http://mds.globus.org/glue/ce/1.1">
                    <agg:PollIntervalMillis>60000</agg:PollIntervalMillis>
                    <agg:ResourcePropertyName>glue:GLUECE</agg:ResourcePropertyName>
                </agg:GetResourcePropertyPollType>
                <trigger:TriggerRuleType>
                    <trigger:matchingRule>
                        //*/glue:GLUECE//glue:ComputingElement[@glue:Name='normal' 
                        and glue:Info/@glue:LRMSType='PBS' 
                        and glue:State/@glue:FreeCPUs>0]
                    </trigger:matchingRule>
                    <trigger:namespaceMappings>
                        xmlns:glue=http://mds.globus.org/glue/ce/1.1
                    </trigger:namespaceMappings>
                    <trigger:actionScript>our-simple-trigger</trigger:actionScript>
                    <trigger:minimumFiringInterval>60</trigger:minimumFiringInterval>
                    <trigger:minimumMatchTime>30</trigger:minimumMatchTime>
                    <trigger:enableFilteredActionScriptInput>true</trigger:enableFilteredActionScriptInput>
                    <trigger:disableUnmodifiedActionScriptInput>true</trigger:disableUnmodifiedActionScriptInput>
                </trigger:TriggerRuleType>
            </agg:AggregatorConfig>
            <agg:AggregatorData />
        </Content>
    </ServiceGroupRegistrationParameters>
</ServiceGroupRegistrations>

Let's break this down to examine a few important parts.

A. Preliminaries

           
<?xml version="1.0" encoding="UTF-8" ?>
    <ServiceGroupRegistrations
            xmlns="http://mds.globus.org/servicegroup/client"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
            xmlns:agg="http://mds.globus.org/aggregator/types">
    </ServiceGroupRegistrations>

As this is an XML document, it must be properly formatted XML.

Start your file with the appropriate header, including relevant namespaces.

The ServiceGroupRegistration node is the root of the document.

B. Aggregator Sink / Service Group Registration Information (for more information, go here).

                                    
<?xml version="1.0" encoding="UTF-8" ?>
    <ServiceGroupRegistrations
        xmlns="http://mds.globus.org/servicegroup/client"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
        xmlns:agg="http://mds.globus.org/aggregator/types">
        <defaultServiceGroupEPR>
        </defaultServiceGroupEPR>
    </ServiceGroupRegistrations>

Although many service group registration blocks may be present, in this example we'll only create one.

                                    
<?xml version="1.0" encoding="UTF-8" ?>
    <ServiceGroupRegistrations
        xmlns="http://mds.globus.org/servicegroup/client"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
        xmlns:agg="http://mds.globus.org/aggregator/types">
        <defaultServiceGroupEPR>
            <wsa:Address>
            https://your-install-location:8081/wsrf/services/DefaultTriggerService
            </wsa:Address>
        </defaultServiceGroupEPR>
        </defaultServiceGroupEPR>
    </ServiceGroupRegistrations>

We will be using the local DefaultTriggerService as our main service group. All registrations from this configuration will be registered to this service.

You can test that the DefaultTriggerService is up and functioning by typing (in one line):

$GLOBUS_LOCATION/bin/wsrf-query -s https://your-install-location:8081/wsrf/services/DefaultTriggerService

Although there may not be much useful output, if you get some XML output, your trigger service should be up and running.

C. Aggregator Source Configuration (for more information, go here).

                                    
<?xml version="1.0" encoding="UTF-8" ?>
    <ServiceGroupRegistrations
        xmlns="http://mds.globus.org/servicegroup/client"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
        xmlns:agg="http://mds.globus.org/aggregator/types">
        <defaultServiceGroupEPR>
            <wsa:Address>
            https://your-install-location:8081/wsrf/services/DefaultTriggerService
            </wsa:Address>
        </defaultServiceGroupEPR>
        <ServiceGroupRegistrationParameters
            xmlns="http://mds.globus.org/servicegroup/client"
            xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
            xmlns:agg="http://mds.globus.org/aggregator/types"
            xmlns:trigger="http://mds.globus.org/2004/08/trigger/types">
        </ServiceGroupRegistrationParameters>
    </ServiceGroupRegistrations>

Now we will specify the parameters used to register a resource (e.g. information provider) to the service group (i.e. our trigger service).

...
<ServiceGroupRegistrationParameters
xmlns="http://mds.globus.org/servicegroup/client"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
xmlns:agg="http://mds.globus.org/aggregator/types"
xmlns:trigger="http://mds.globus.org/2004/08/trigger/types">
<RegistrantEPR
    xmlns:gram="http://www.globus.org/namespaces/2004/10/gram/job"
    xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">
    <wsa:Address>
    https://cluster-location-with-pbs:8443/wsrf/services/ManagedJobFactoryService
    </wsa:Address>
    <wsa:ReferenceProperties>
    <gram:ResourceID>PBS</gram:ResourceID>
    </wsa:ReferenceProperties>
    </RegistrantEPR>
</ServiceGroupRegistrationParameters>
...

We will set the RegistrantEPR to the entity (or information provider) to be monitored.

In this case, we will be monitoring the ManagedJobFactoryService of a GT4 deployment on a cluster with PBS.

We must also set the ResourceID to: PBS.

...
<ServiceGroupRegistrationParameters
    xmlns="http://mds.globus.org/servicegroup/client"
    xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
    xmlns:agg="http://mds.globus.org/aggregator/types"
    xmlns:trigger="http://mds.globus.org/2004/08/trigger/types">
    <RegistrantEPR
        xmlns:gram="http://www.globus.org/namespaces/2004/10/gram/job"
        xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">
        <wsa:Address>
            https://cluster-location-with-pbs:8443/wsrf/services/ManagedJobFactoryService
        </wsa:Address>
        <wsa:ReferenceProperties>
            <gram:ResourceID>PBS</gram:ResourceID>
        </wsa:ReferenceProperties>
    </RegistrantEPR>
    <RefreshIntervalSecs>600</RefreshIntervalSecs>
</ServiceGroupRegistrationParameters>
...

Set the RefreshIntervalSecs parameter to the number of seconds upon which the registration will be renewed (this is to keep the registration from expiring): 600.

"600" indicates that we'll renew the registration every 10 minutes.

...
<ServiceGroupRegistrationParameters
xmlns="http://mds.globus.org/servicegroup/client"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
xmlns:agg="http://mds.globus.org/aggregator/types"
xmlns:trigger="http://mds.globus.org/2004/08/trigger/types">
<RegistrantEPR
xmlns:gram="http://www.globus.org/namespaces/2004/10/gram/job"
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">
<wsa:Address>
https://cluster-location-with-pbs:8443/wsrf/services/ManagedJobFactoryService
</wsa:Address>
<wsa:ReferenceProperties>
<gram:ResourceID>PBS</gram:ResourceID>
</wsa:ReferenceProperties>
</RegistrantEPR>
<RefreshIntervalSecs>600</RefreshIntervalSecs>
<Content xsi:type="agg:AggregatorContent"
    xmlns:agg="http://mds.globus.org/aggregator/types">
    <agg:AggregatorConfig xsi:type="agg:AggregatorConfig">
    </agg:AggregatorConfig>
    </Content>
</ServiceGroupRegistrationParameters>
...

Now we configure aggregator-source-specific configuration parameters.

...
<Content xsi:type="agg:AggregatorContent"
xmlns:agg="http://mds.globus.org/aggregator/types">
<agg:AggregatorConfig xsi:type="agg:AggregatorConfig">
<agg:GetResourcePropertyPollType
    xmlns:glue="http://mds.globus.org/glue/ce/1.1">
    <agg:PollIntervalMillis>60000</agg:PollIntervalMillis>
    </agg:GetResourcePropertyPollType>
</agg:AggregatorConfig>
<agg:AggregatorData />
</Content>
...

Set this to how often you'll be polling the information provider for data and refreshing the current information: 60000.

"60000" indicates that you'll be checking the information provider every minute.

...
<Content xsi:type="agg:AggregatorContent"
xmlns:agg="http://mds.globus.org/aggregator/types">
<agg:AggregatorConfig xsi:type="agg:AggregatorConfig">
<agg:GetResourcePropertyPollType
xmlns:glue="http://mds.globus.org/glue/ce/1.1">
<agg:PollIntervalMillis>60000</agg:PollIntervalMillis>
<agg:ResourcePropertyName>glue:GLUECE</agg:ResourcePropertyName>
</agg:GetResourcePropertyPollType>
</agg:AggregatorConfig>
<agg:AggregatorData />
</Content>
...

Set this to the name of the resource property that the data is accessed by: glue:GLUECE.

[The format is rp_namespace:rp_localname]

You can view some active ResourcePropertyNames as you poll the DefaultIndexService.

D. Trigger Configuration Information (for more information: go here).

...
<Content xsi:type="agg:AggregatorContent"
xmlns:agg="http://mds.globus.org/aggregator/types">
<agg:AggregatorConfig xsi:type="agg:AggregatorConfig">
<agg:GetResourcePropertyPollType
xmlns:glue="http://mds.globus.org/glue/ce/1.1">
<agg:PollIntervalMillis>60000</agg:PollIntervalMillis>
<agg:ResourcePropertyName>glue:GLUECE</agg:ResourcePropertyName>
</agg:GetResourcePropertyPollType>
<trigger:TriggerRuleType>
    </trigger:TriggerRuleType>
</agg:AggregatorConfig>
<agg:AggregatorData />
</Content>
...

Now that we've set up the aggregator source to monitor an information provider (the ManagedJobFactoryService) and set a trigger (the DefaultTriggerService) as the aggregator service/sink, we will configure the trigger.

...
<trigger:TriggerRuleType>
<trigger:matchingRule>
//*/glue:GLUECE//glue:ComputingElement[@glue:Name='normal'
and glue:Info/@glue:LRMSType='PBS' 
and glue:State/@glue:FreeCPUs>0]
</trigger:matchingRule>
</trigger:TriggerRuleType>
...

Set this to the XPath rule you wish to compare and match against incoming data. It will ideally fit on one line.

We can test this query using wsrf-query as we did above while setting up the GT4 environment.

...
<trigger:TriggerRuleType>
<trigger:matchingRule>
//*/glue:GLUECE//glue:ComputingElement[@glue:Name='normal' 
and glue:Info/@glue:LRMSType='PBS' 
and glue:State/@glue:FreeCPUs>0]
</trigger:matchingRule>
<trigger:namespaceMappings>
    xmlns:glue=http://mds.globus.org/glue/ce/1.1
    </trigger:namespaceMappings>
</trigger:TriggerRuleType>
...

If you use namespace prefixes in the above XPath matchingRule, you can specify an array of namespace mappings that will be used to resolve the namespace prefixes.

The format is: xmlns:foo=http://foo.bar.

	Important
	In this example, this parameter is required.

...
<trigger:TriggerRuleType>
<trigger:matchingRule>
//*/glue:GLUECE//glue:ComputingElement[@glue:Name='normal' 
and glue:Info/@glue:LRMSType='PBS' 
and glue:State/@glue:FreeCPUs>0]
</trigger:matchingRule>
<trigger:namespaceMappings>
xmlns:glue=http://mds.globus.org/glue/ce/1.1
</trigger:namespaceMappings>
<trigger:actionScript>our-simple-trigger</trigger:actionScript>
</trigger:TriggerRuleType>
...

Set this to the name of the action script that will be executed when the matchingRule matches any nodes of incoming data: our-simple-trigger.

This logical name must be mapped to a physical file name located in the $GLOBUS_LOCATION/libexec/trigger/ directory.

The logical-to-physical filename mapping is specified in the executableMappings parameter of the triggerConfiguration block of the file: $GLOBUS_LOCATION/etc/globus_wsrf_mds_trigger/jndi-config.xml.

Don't worry about these files now, we'll revisit them in the next section.

...
<trigger:TriggerRuleType>
<trigger:matchingRule>
//*/glue:GLUECE//glue:ComputingElement[@glue:Name='normal' 
and glue:Info/@glue:LRMSType='PBS' 
and glue:State/@glue:FreeCPUs>0]
</trigger:matchingRule>
<trigger:namespaceMappings>
xmlns:glue=http://mds.globus.org/glue/ce/1.1
</trigger:namespaceMappings>
<trigger:actionScript>our-simple-trigger</trigger:actionScript>
<trigger:minimumFiringInterval>60</trigger:minimumFiringInterval>
</trigger:TriggerRuleType>
...

Set this to the number of seconds no more than which you want the action script to be executed: 60.

"60" indicates the action script will be executed no more than once every minute.

If unspecified, there will be no minimum interval, and it will be fired whenever incoming data matches the matchingRule.

...
<trigger:TriggerRuleType>
<trigger:matchingRule>
//*/glue:GLUECE//glue:ComputingElement[@glue:Name='normal' 
and glue:Info/@glue:LRMSType='PBS' 
and glue:State/@glue:FreeCPUs>0]
</trigger:matchingRule>
<trigger:namespaceMappings>
xmlns:glue=http://mds.globus.org/glue/ce/1.1
</trigger:namespaceMappings>
<trigger:actionScript>our-simple-trigger</trigger:actionScript>
<trigger:minimumFiringInterval>60</trigger:minimumFiringInterval>
<trigger:minimumMatchTime>30</trigger:minimumMatchTime>
</trigger:TriggerRuleType>
...

Set this to how long the matchingRule must be true before the action script will be executed: 30

"30" indicates the condition must be true for 30 seconds before the actionScript will be eligible to fire.

If unspecified, the trigger will be eligible to fire immediatedly after the matchingRule properly matches incoming data.

...
<trigger:TriggerRuleType>
<trigger:matchingRule>
//*/glue:GLUECE//glue:ComputingElement[@glue:Name='normal' 
and glue:Info/@glue:LRMSType='PBS' 
and glue:State/@glue:FreeCPUs>0]
</trigger:matchingRule>
<trigger:namespaceMappings>
xmlns:glue=http://mds.globus.org/glue/ce/1.1
</trigger:namespaceMappings>
<trigger:actionScript>our-simple-trigger</trigger:actionScript>
<trigger:minimumFiringInterval>60</trigger:minimumFiringInterval>
<trigger:minimumMatchTime>30</trigger:minimumMatchTime>
<trigger:enableFilteredActionScriptInput>
    true
    </trigger:enableFilteredActionScriptInput>
</trigger:TriggerRuleType>
...

Set this to true since we will be parsing the output provided by the trigger and passing this to the action script.

...
<trigger:TriggerRuleType>
<trigger:matchingRule>
//*/glue:GLUECE//glue:ComputingElement[@glue:Name='normal' 
and glue:Info/@glue:LRMSType='PBS' 
and glue:State/@glue:FreeCPUs>0]
</trigger:matchingRule>
<trigger:namespaceMappings>
xmlns:glue=http://mds.globus.org/glue/ce/1.1
</trigger:namespaceMappings>
<trigger:actionScript>our-simple-trigger</trigger:actionScript>
<trigger:minimumFiringInterval>60</trigger:minimumFiringInterval>
<trigger:minimumMatchTime>30</trigger:minimumMatchTime>
<trigger:enableFilteredActionScriptInput>
true
</trigger:enableFilteredActionScriptInput>
<trigger:disableUnmodifiedActionScriptInput>
    true
    </trigger:disableUnmodifiedActionScriptInput>
</trigger:TriggerRuleType>
...

Set this to true to increase performance by not passing the original trigger message input (to which the matching rule was applied) to the action script.

That's all for the trigger configuration. Now we need to set up the action script and register the trigger.

4. Step 3 - Set up the trigger action script

Write the trigger action script:

The action script can be written in almost anything, but it must output valid XML to stdout.

We will be using a Perl script to parse a bit of the trigger output and format this information, then write it to a log file.

If you would like to receive email notification in addition to a log trace, see this tutorial, which extends this section using the same example.

You may copy the contents of the following Perl script. It is not necessarily the best way to write a script, but it gives you an example of what is possible!

This action script will be created here: $GLOBUS_LOCATION/libexec/trigger/our-simple-trigger-action.pl.

                                
#!/usr/bin/perl

# CHANGE THIS to where you want to place your log file.  
# DO NOT use an environment variable in this example; it should be the full path.
$logfile = "/your-install-location/our_new_entry_detected";

# Grab the date
$date = `date`; chomp($date);

# Collect the trigger input
$string = <STDIN>;

# Check on the log file
$OUTFILE = $logfile;if(!open(OUTFILE, ">>$logfile"))
{warn "Couldn't open $logfile for appending: $!";}

# Split the output to separate lines
$string =~ s/</ggg</g;
my @records = split("ggg",$string);

our @newrecs;

# Parse each line of input for signs of FreeCPUs
foreach $record (@records)
{
if($record =~ /FreeCPUs=\W+(\d+)\W+/) {
$str = "$date :: FreeCPUs: $1\n";
# This step adds the occurences to an array, and you
# can decide what you want to do with it.
push @newrecs, $str;
}
}

# Output the first line of the array to the logfile.
print OUTFILE ($newrecs[0]);

# NOTE, in the case that the FreeCPU occurences are not identical, 
#you can decide which values are more important for your purposes.

# All trigger action scripts must output valid XML.
print "<?xml version=\"1.0\" encoding=\"UTF-8\"?>
<OurActionScriptOutput>
<OurDataDetected>true</OurDataDetected>
</OurActionScriptOutput>";

Modify the permissions:
Change permissions on the action script. Be sure the the action script is executable:
```
chmod a+x $GLOBUS_LOCATION/libexec/trigger/our-simple-trigger-action.sh
                
```

Edit the jndi-config.xml file:

Remember in our trigger configuration file, we specified the name of our action script ("our-simple-trigger") using the <trigger:actionScript> node.

Now we must edit the file: $GLOBUS_LOCATION/etc/globus_wsrf_mds_trigger/jndi-config.xml

Find the executableMappings section of the file, and we will add our trigger action script mapping to the file:

                ...
                <jndiConfig>
                    <global>
                        
                        <resource name="triggerConfiguration">
                            <resourceParams>
                                <parameter>  
                                    <name>executableMappings</name>
                                    <value>test-trigger=test-trigger-action.sh, 
                                        glue-trigger=glue-trigger-action.sh, 
                                        echo-trigger=echo-trigger-action.sh,   
                                        our-simple-trigger=our-simple-trigger-action.sh
                                    </value>
                                </parameter>
                            </resourceParams>
                        </resource>
                    </global>
                </jndiConfig>
                ...

	PLEASE note that this section may be commented out. You must uncomment it!
	Don't forget to add a comma here.

5. Step 4 - Create the trigger

The trigger is virtually created when you write the configuration file, but it is not really created until it is registered. It is now time to register the trigger.

The registration step is necessary to connect the information source with the Trigger (aggregator service). This step provides access to the information source data so that the trigger can then make this information available and act on it accordingly.

Start the container:
You may have noticed that we used port 8081 in the trigger configuration file. You can specify this by using the -p parameter:
```
$GLOBUS_LOCATION/bin/globus-start-container -p 8081
```
You may also need to generate a new proxy certificate:
```
$GLOBUS_LOCATION/bin/grid-proxy-init -verify -debug
```
If security is not enabled, you could try to start the container without enforcing security using the -nosec parameter:
```
$GLOBUS_LOCATION/bin/globus-start-container -p 8081 -nosec
```

Register the trigger:

We will now run mds-servicegroup-add to perform the registrations specified in the configuration file. This tool takes an XML configuration file listing registrations, and causes those registrations to be made.

Run the following command (be sure this command is on one line):

$GLOBUS_LOCATION/bin/mds-servicegroup-add -s https://your-install-location:8081/wsrf/services/DefaultTriggerService $GLOBUS_LOCATION/etc/globus_wsrf_mds_trigger/our-simple-trigger-config.xml

If everything went well, you should get something like:

            
Processing configuration file...
Processed 1 registration entries
Successfully registered https://cluster-location-with-pbs:8443/wsrf/services/ManagedJobFactoryService\
to servicegroup at https://your-install-location:8081/wsrf/services/DefaultTriggerService

6. Step 5 - Test the trigger

Now that our trigger is registered, it's ready to perform actions. We set our trigger to fire about every two minutes or so to let us know how many FreeCPUs there are. We also set our action script to parse and log this information to a convenient location: "/your-install-location/our_new_entry_detected"
Now we want to check that file to see if a new entry/log has been recorded.

After a few minutes, if everything went properly, we should be able to open the file: /your-install-location/our_new_entry_detected and see something like the following:

            
Mon Nov 27 18:00:52 PST 2006 :: FreeCPUs: 66
Mon Nov 27 18:01:52 PST 2006 :: FreeCPUs: 66
Mon Nov 27 18:03:52 PST 2006 :: FreeCPUs: 66
Mon Nov 27 18:04:52 PST 2006 :: FreeCPUs: 66
Mon Nov 27 18:06:52 PST 2006 :: FreeCPUs: 74
Mon Nov 27 18:07:53 PST 2006 :: FreeCPUs: 74

Troubleshooting

The main areas where trouble may arise in this example are in making sure that the action script is properly written. Here are some guidelines:

Turn on debugging by adding the following line to your $GLOBUS_LOCATION/container-log4j.properties file:
```
log4j.category.org.globus.mds.trigger=DEBUG
```

If you are getting the following error:

            
2006-11-27T16:11:01,186-08:00
WARN impl.TriggerResource
[org.globus.mds.aggregator.impl.PollingAggregatorSource$QueryTimerListener,deliver:677]
Exception while attempting to execute the trigger action:
java.lang.Exception: Exception while parsing output from action script:
org.xml.sax.SAXException: Fatal Error: URI=null Line=-1: Premature end
 of file.

...it's most likely due to your action script.

Important

Be sure that your script outputs valid XML to stdout, and nothing else! This is important because if your script returns an error or warning, for instance (which is typically not XML), you will get the above error. This makes things somewhat difficult to debug, but try testing out your script in a separate instance so that you can get most of the bugs out, then try to use it with your trigger. Or simplify your action script and then gradually add complexity until you find out where it stops working.

7. Congratulations!

If all went well, then you have successfully set up a trigger! Explore the possibilities by creating your own scripts and XPath conditions. Use the HowTos to assist you and have fun creating triggers!

Prev	Up	Next
GT 4.1.1 WS MDS Trigger Service: Quality Profile	Home	Trigger Service HOWTO - Using Triggers To Notify By Email