4.10.1 Adapt the schedule
In principle, ARIS Risk & Compliance Manager provides two possibilities for starting automated jobs in order to generate or change objects. For the first possibility with the corresponding manager role you can trigger a job manually via the ARIS Risk & Compliance Manager interface.
The second possibility is the scheduled execution of the job by ARIS Risk & Compliance Manager . In the default configuration this is for example, the case for the generator and monitoring jobs.
Scheduled jobs are entered in the runtimeconfig.xml file. Within the <section id="scheduler"> tag every scheduled job has a parameter list.
Example
<parameterList name="monitorJobTestcase">
<parameter name="jobitem" value="monitorJob" />
<parameter name="startScheduler" value="true"/>
<parameter name="executionTime" value="0 52 01 ? * SUN-SAT"/>
<parameter name="clientexcludinglist" value=""/>
<parameter name="clientincludinglist" value=""/>
<parameter name="objecttypes" value="TESTCASE"/>
</parameterList>
The name of the parameter list can be selected freely, it must however be unique within the parameter lists. The individual parameters have the following meaning:
Jobitem
The job to be executed. The parameter value must correspond to a EnumItem ID from the jobs enumeration in the enumerations.xml file.
startScheduler
Must be true so that the time control for this job is active.
executionTime
This expression states at which point in time the job should be started. It has the format CronTrigger that allows the specification of time intervals.
The individual values mean the following from left to right:
Seconds (0-59)
Minutes (0-59)
Hours (0-23)
64
Day of month (1-31)
Month (1-12 or JAN-DEC)
Day of week (1-7 or SUN-SAT)
Year (may be empty, 1984, 1970-2099, ...)
In the example above, the monitor job for checking test cases each day every month starts at 01:52. Further information can be found in the CronTrigger documentation on the Quartz home page (http://www.quartz-scheduler.org (http://www.quartz-scheduler.org))
clientexcludinglist
The clients in the ARIS Risk & Compliance Manager database for which the job should not be executed are listed here. The values can be specified comma-separated.
Clientincludinglist
The clients in the ARIS Risk & Compliance Manager database for which the job should be executed are listed here. If no value is specified, a separate job is started for each individual client. The values can be specified comma-separated.
Objecttypes
The object types for which the job should be executed. In the example above, this instance of the monitoring job should only check the test cases. The values can be specified
comma-separated.
4.10.2 Generator
4.10.2.1 Adapt the object search
The search for initial recurring objects, such as a test definition for test cases or a risk for risk assessment is controlled in the default configuration via the file
commandchains_generator.xml. It includes a generator_[target type] chain, which is linked to either the RecurringObjectSearchCommand command or a derivation of it.
This command is responsible for finding all recurring objects that come into consideration for the generation of transactional objects. These objects or rather their OVIDs are written by Command in the CommandChainContext and from there extracted and reused by the generator.
Location XML file in the xml folder
Procedure Copy the appropriate <catalog> from the default configuration to customizing.
Then, adapt the command chain.
Documents commandClassMapping.xml, blClassMapping.xsd, commandchains_generator.xml, commandchains.xsd
65
4.10.2.2 Generate objects
The generator creates an empty transactional object for each OVID of a recurring object that the generator receives by performing the object search. Whether this object can be filled and saved correctly is determined by the workflow configuration of the transactional object.
For each transactional object type in the workflow, there is a connection in <state.initial> with only the generator job as authorized (permission). When the object is created the generator follows this workflow connection.
Example for the TESTCASE object type
Command chain prepareJob in the testcase catalog.
The chain with which the transactional object is checked and filled is defined on this workflow connection. The first part of the chain consists of derivations of the
GeneratorConditionCheckCommand class, each of which checks for the relevant recurring object (e.g., test definition) whether all conditions for the generation are met. The second part consists of a derivation of GenerateCommand. This is where for example, test case or attribute value are assigned to the new transactional object. Since these are commands, the behavior can be adapted by omitting, replacing, and supplementing.
After the chain described above has been successfully completed the transactional object has the
<state.prepared> status. This means that the generator creates the object, but the object is not yet persistent. In the second step, the generator follows the connection for which it is authorized (permission) and which leads to the first workflow status that allows manual
processing by the user. In the default configuration these are the states on which the tasks for the owner or the creator are defined.
Example for the TESTCASE object type
Command chain insertJob in the testcase catalog.
The command prepareJobMessageCommand within this second connection defines which notifications should be sent to the owner. During its cycle the generator collects the messages from all of the created objects, combines them as best possible and sends them to the recipients defined above.
Location XML file in the xml folder
Procedure Copy the appropriate <catalog> from the default configuration to customizing.
Then, adapt the command chain.
Documents commandClassMapping.xml, blClassMapping.xsd,
commandchains_[module].xml,
commandchains.xsd, workflow_[module].xml
66
4.10.3 Monitoring job
4.10.3.1 Adapt the object search
The monitoring job can be adapted so that you can specify for transactional objects (e.g., test case) via their workflow whether they are to be included in the monitoring job or not. If an object in a specific workflow state is to be controlled by the monitoring job, a task item must be entered at the state. In the default configuration, these are the states that symbolize the editing carried out by the owner group.
Location XML file in the xml folder
Procedure Copy the appropriate workflow to customizing. Then, modify the <task.item>
elements at the individual states.
Remark Make sure that the time.limitation property in the task definition is not set to false, otherwise, the monitoring job will ignore these tasks.
Documents workflow.xsd, workflow_[module].xml
4.10.3.2 Escalations
The file escalations.xml specifies how the monitoring job handles the objects found. The escalations defined in this file , represented by the <escalation> item, must have the same role, name and object type as the task. An escalation encompasses defined levels that are represented by <level> elements. The monitoring job calculates how much processing time has already elapsed and which level has been currently reached.
A certain level is reached when a specific percentage of the processing time has expired
(percentage attribute) or when the end of the processing time has been reached within a certain number of days/hours (remainingTime attribute). If the next level has been reached this is noted at the task and a corresponding message is sent to the relevant user group. The type of message, the group of recipients and attribute changes to the object referenced by the task can also be adjusted:
With the <attributeChange> subordinate elements you can define which attributes of the referenced object should receive which value. The id property states the attribute to be changed. Value states the new value for the attribute. For example, in the default configuration test cases that have expired 100% are set to the nottested state.
Attribute changes are tantamount to changes to the object in the form, i.e. they can trigger state transitions in the workflow. In principle such attribute changes can only be specified for levels with the percentage 100%.
With the <escalationMessage> subordinate elements you can change the group of recipients, the message template to be used and the list linked in the message.
67
If a level has no such subordinate elements or no recipient groups have been stated the message is always sent to the task owner.
If a level has no such subordinate elements or no message templates are stated the monitorjob default template is used. Your own personal message template may contain any text, must however at least contain the $monitorLog placeholder.
If a level has no such subordinate elements or a link to a list is not stated a default link is opened that calls up the owner list for this object depending on the object type.
Location XML file in the xml folder
Procedure Copy the relevant <escalation> elements and add new <level> subordinate elements. If <attributeChange> subordinate elements exist for a level, they will be applied to the object. If a level has <escalationMessage> subordinate elements these are taken into account by the monitoring job when the message is sent.
Documents escalations.xml, escalations.xsd Example Escalations_ModifyLevels
\WEB-INF\config\custom\xml\custom.xml
4.10.4 Updater
Location XML file in the xml folder Procedure See Generator (Page 64) Documents Commandchain_update.xml