SCIFF Checker is a JAVA-based ProM plug-in capable to classify a set of MXML execution traces as compliant/non- compliant w.r.t. a declarative business rule, specified following the CLIMB paradigm. The main distinctive feature of SCIFF Checker is that while in CLIMB constraints fix the involved activities, here activities are considered as variables (which can be constrained); involved originators and execution times are also variables and can be constrained as well. In this way, the set of CLIMB constraints can be configured to model many different expressive business rules.

SCIFF Checker provides a GUI which renders a set of business rules templates (i.e. a set of “generic” constraints containing variables) using an intuitive textual IF...THEN notation, and allows the user to configure them by imposing constraints. As an example, let us consider the response template, which is rendered as:

IF Activity A is performed
THEN Activity B must be performed
s.t. B.execTime is greater than A.execTime

Note that activities are not specified, whereas execution times are constrained to express an after relationship. The user can configure such a template in many different ways. For example:

IF Activity A is performed
s.t. A.activityType = ‘pay item’
THEN Activity B must be performed
s.t. B.activityType = ‘send receipt’
AND B.originator != A.originator
AND B.execTime is greater than A.execTime
AND B.execTime is lower than A.execTime + 3 days

specifies that if the “pay item” activity is executed, then the activity “send receipt” must also be executed by a different person, after the item payment but within a deadline of three days.
Another interesting example is the well-known four-eyes principle, which states that the same originator cannot perform two different activities. The corresponding SCIFF Checker template is:

IF Activity A is performed
THEN Activity B should not be performed
s.t. B.originator = A.originator

After having configured the rule, it is possible either to save it and re-use it later, or check it against the MXML execution traces by exploiting our SWI Prolog and JPL). The result is a pie which counts how many compliant and non-compliant execution traces have been found. It is then possible to re-iterate analysis by considering only one of these sub-sets, or even use the obtained classification as input of DecMiner, to realize the so called mining-checking cycle.