Configure Reporting Rules

Contents

 

Reporting rules engine

 

"The Reporting Rules Engine enables extensive modifications to the printing process flow without the need for invasive code changes."

This would in turn reduce project time and total cost of ownership.

Configuration

You may find Report Rule configuration forms at IFS Applications -> Solution Manager -> Reporting -> Operational Reporting

Report Rule Overview

You can view or create new report rules from the report rule overview.

Report rule overview will have fields for Rule Id, Description, Reprot ID, property, No Multy and Enabled .

If you create a new rule, it will generate a unique Rule Id with a value grate than the existing Rule ids.

You can use Description give a meaning to the rule.

Priority number will decide in which order a report rule will overrule other rules. Rules with same Priority will execute in the order of Rule Id .

One Report ID can be set on one rule. Not setting a Report ID would result the rule being applied to all the reports. Report ID will be used to help in setting up values for Conditions and Actions for rules later.

No Multi checked will not allow the rule to run for multiple reports if you select many reports for single print job. By default this rule will be checked. If you uncheck this, make sure that you have no action that would violate the confidentiality of the reports (eg. Emails sent after printing etc…).

 

Report Rule

Selecting one or more rules from Report Rule Overview, you can drill down to more details using View option from the context menus. A report rule has Conditions and Actions. When the Conditions are fulfilled, set Actions will execute.

Conditions

Conditions table have Ordinal , Logical operator , Expression 1 and Expression2 , Operator and parenthesis ( , ) fields.

Ordinal is a number which would define ordinal of conditions. You can change the Ordinal value to set the order of condition being interpreted.

Logical operator sets the logical relationship among conditions.
And parenthesis of either ( , ) can be used to group conditions with logical operators.

Expression can be any value including report properties, SQL statements, XPath or any combination of them which would reflect a final value. When you work with expressions, you can get help form Edit expression dialogs. Select Edit Expression from context menu.

 

Set Expressions dialog will help you find a value in the report using XPath from the Report XML and selecting Variables from the report process .Selecting XPath is only possible if the rule has defined a Report ID. Selecting Variables will set values from the report process to the expression. See Expressions for more information.
Values from the Expressions can be compared using Operator .

Actions

Actions table have Ordinal , Type , Property List and Enabled fields.

Ordinal is a number which would define ordinal of Actions. You can change the Ordinal value to set the order of Actions being executed.

Actions have types. you can select the Action type in the Type field.

Certain action types can have certain properties. You can set values for properties in the Property List field. Action Properties dialog will help you to find relevant properties for a selected Action type. Select ‘Edit Action Properties’ from the context menu to open Action Properties dialog.

 

Expressions

Expressions in both conditions and Actions can be of 3 types

 

You can use this as a programming language where each expression works as a placeholder for some value.

e.g

[&select identity from fnd_user where web_user=’[#Current_User]’]

[&ARCHIVE_API.Get_Report_Title(‘[#Reportid]’)]

Action types and report rule engine

In the normal process of ordering a report, the print dialog will make a call to the report rule engine. Based on the properties given by the report rule engine it will set up the print job properties of the print dialog.

When the user press ok or preview, a format request will be made to the report formatter. The report formatter will make another call to the report rule engine to check if any other rules need to be applied after the defaults are being applied.

Print dialog shows the default properties and forced properties for a print job. There are several levels of setting up these defaults using actions.

  1. Preselect Property
    If you decide to set an action with type Preselect Property, properties of that action will be set in print properties in the print dialog by default.
  2. Set Default Property
    If you set an action type of Set Default Property it will set pre-selected properties in the action to the report dialog. However when the report format request is made the report formatter will also check for the default properties in the action and will apply these settings which would not override any changed setting from the print dialog. These settings may come in use when print jobs are directly sent from application without going through the print dialog
  3. Set Property
    If you set an action type if Set Property it will set properties in the print dialog with a lock. This way you cannot change the pre-select values. Further, this means that the report formatter will override all the settings if pre-selected.
  4. Route To Connect
    If you want to route any type of application message to IFS Connect, you can use Route To Connect rule action. There you will need to define the Transport connector, Connector Instance and some other IFS Connect properties. There are some concerns when using this rule action.

    - The Transport Connector and the Sender Instance should be corresponding to each other, if not, the priority will be given to the Transport Connector and the default Sender Instance will be selected.
    (Ex : If the Transport Connector is 'File', the Sender Instance should be 'FILE_SENDER1'.)

    - If you need the resultant report (pdf) to be attached in the application message (Ex: 'File' or 'Mail'), then you will need to set the TYPE property of Route To Connect rule action as REPORTING. Any other value for TYPE will not attach the PDF in the resultant application message. Without setting TYPE as REPORTING, you can still get the PDF in the resultant application message by keeping the MESSAGE property blank.

    (Ex : Suppose you configured a rule to send a mail. To get the PDF attached in the resultant mail, you will need to select Transport Connector as 'Mail', Sender Instance as 'MAIL_SENDER1', set Type as REPORTING or keep Message box blank.)
  5. Send Email
    This rules provide the capability to send the resulting PDF over Email. The functionality is built on top of the Route Reports based on Content mechanism, this generates the routing xml snippet required for sending an Email. This rule will not override existing Routing Email Destinations.
  6. Print To Logical Printer
    This rules provide the capability to control the Print Agent. Eg: change the Logical printer of print job and redirect the print job to a different Print Agent. The functionality is built on top of the Route Reports based on Content mechanism, this generates the routing xml snippet required for Routing the Print job. This rule will not override existing Routing Printer Destinations.
  1. Change System Settings
    This action type can temporarily overrule some system parameter properties. Namely these are the Report Designer graphics path, make Report Designer PDF/A compliant, spooling from Report Formatter and the breakpoint XML size for when to format Report Designer reports in memory or using disk storage.

           

Apart from the actions mentioned above there are other actions such as ‘Change System Settings’. This action can temporarily overrule some system properties.

Import/Export Report rule

Right mouse menu options available on each row, allow the report rule to be imported and exported to and from the database.

Report rule log


Report rule log will help you trace rule execution. This will be useful when designing rules.
Report rule log will give information on.