There was a problem loading the comments.

Rule Pack Add-Ons for Event Server - Using File Rules, SQL Rules, and Mail Rules

Support Portal  »  Knowledgebase  »  Viewing Article

Jeff-Net Report Runner Batch Event Server is a service that monitors an input queue for an "instructional" Crystal Reports file, and automatically processes it. It accomplishes this by watching for a Report Runner Batch (Enterprise Version Only) XML input files to 'hit' a designated input directory. This is a great option for applications or websites looking to allow users to create batches of reports and process them on-the-fly. If the batch file is processed successfully, it is moved to a "Processed" directory. If there is a problem, it is moved to an "Error" directory. Combined with our Report Runner Batch software, this add-on allows you to automate any kind of report processing of your own.

We have many customers utilizing it for custom web-based applications as well as custom software and needs in-house. Here are just a few examples of what our customers have used this solution for is:

1) Automatically generating and printing helpdesk tickets to helpdesk users, printing it on their local printer at their desk, and triggering all of it using a database trigger each time the helpdesk user opens a ticket

2) Generating books, catalogs, and proposals on demand (using our bursting and PDF combining technology)

3) Automatically emailing an invoice in PDF format each time an order record is created in an online web store

We also support event-based triggers via email, files, or SQL. Imagine setting up an email portal for Crystal Reports. How cool would it be if someone could simply email a request for a report to be run and it happen automatically? We can do it! Using our Mail Rules for Event Server, you can set up email parsing rules so when a user emails a special email account (like, Event Server will read the request, run the report, and send the user the report requested via email. We can also trigger batches and reports to run based on File Rules triggers (like a nightly incoming FTP file) and SQL triggers. The SQL Rules triggers would simply monitor for certain "flags" to be set in a table and trigger batches and reports once that flag is set. Before running the triggered XML file, it can run another SQL statement to indicate "it's running". Afterwards, the SQL Rules triggers can optionally set a flag back to another value (to indicate "it's finished").


Installing and Using The Rules:

The rule data files are installed when you install Report Runner Batch the first time. You just don't see them or use them. And you edit the rules using Report Runner Batch, under the Tools menu. Note, if the rules buttons are disabled under the Tools menu, you need to rerun the Event Server installer and choose a time greater than 0 for the various rules to trigger and run. Leaving the scan time at 0 disables the rules.

All of the various rules work pretty much as you would imagine. We try to make all of our software work the way you would imagine for that matter. You may create as many rules as you like, to handle any business need. There's nothing "extra" to do to activate them. If they are "ON" and you're licensed for Event Server and the various rule packs, Event Server takes care of everything else.

Let's look at the various rule edit windows...


File Rules:

File Rules

File rules allow you to simply configure a rule that says:

1) Look for this file in this directory

2) Once found, run this Batch XML file

3) After the Batch XML file is complete, do this to the file found in step #1 (delete, move, rename)

Note, Event Server does not update the Batch XML file with the file found before running. Mail Rules are the rules that optionally can update the XML file before running it.


SQL Rules:

SQL Rules

SQL Rules go by this thought process:

1) Write a SQL Select statement to look for a certain value. If found, time to run a Batch XML file.

2) Optionally write an SQL Update statement to indicate you're running a Batch XML file. Many customer use this to update a value that says "hold off processing XYZ until this is done".

3) Write a SQL Update statement that indicates the value found in step #1 is done. In other words, "I'm done processing so XYZ can now continue".

As noted in the edit window, you can test the update all statements from the window. It's not just a syntax check, the SQL code actually gets executed.


Mail Rules:

Before going further, let's make sure you're aware of how the XML data files are laid out and how you can "manually" update the Batch XML data files. It's important to have an idea of this before looking at the mail rules. The reason is this... the mail rules allow for your Batch XML file fields to be updated using data from the email, before calling Event Server to process the XML file.

Check out this KB article and then come back to this one:

Ok, now you have an idea of how the XML file is structured, let's look at the mail rule window. It should make a lot more sense to you.

Mail Rules

The mail rules allow you to:

1) Check a mail account for email

2) Scan that mail for values in from address and/or subject and/or message

3) If found, optionally parse the mail subject and email message for values (found after and before whatever), and set specific fields in the XML file to found value

4) Optionally, if email-based Batch XML file, update the email destination field with email address of sender (ie. auto-reply to sender)

5) Optionally, delete the email from the queue if it triggered a Batch XML file

Note, Event Server keeps track of the last mail message read and it will not re-read those mail messages.

The idea with these mail rules is that they would not scan someones personal email account (although it's technically possible)... the recommended setup would be to have a separate email account just for these report requests that only get scanned by our software. And assuming no SPAM sent to this account and all requests were legit and you configured it to remove processed email, the email account would stay very clean/empty, and it would not build up a large number of "unread" emails.

If you would like to test/demo/see working mail rules, follow these steps to send a test email to us:

1) Create an email to smtp(at)

2) Set the Subject to "Mail Events Test" (no quotes)

3) In the body of the message type "Parm=ANYTHING YOU WANT TO TEST WITH" (no quotes and message can be anything)

Send the email and give it a few minutes to respond with report attached and the message you passed after Parm=.


Those are the basics of the rule packs for Event Server. Check them out and let us know if you have any questions!

Share via

Related Articles

© Support @ Jeff-Net