You can use the following examples of automated qualifiers written in Java with any rule type.
Depending on whether you need the old object or the current object, different methods are necessary for getting values of an object. In these examples, the values in the current object are used unless otherwise stated.
You can find the following automated qualifier samples in this section:
•Comparing Custom Field Values
•Checking Whether System Field Values Were Changed
•Checking Whether Custom Field Values Were Changed
•Checking Roles in Related Records
•Checking Default Category in Related Records
•Checking Values in Vendor's Contact Record
•Checking Whether Custom Field Has a Value
Checking System Field Values
Both the total amount and activity item are system fields in task records (instances of Task). Therefore, the interface Task has specific methods to get their values.
The activity items in task records are system lookup table items. For more details, see Lookup Tables and List Fields.
Business Rule |
No tasks that are over $10,000 with the activity item Printing can be posted without approval. |
Qualifier |
Checks whether: •The total task amount is over $10,000. •The task's activity item is Printing. |
Sample Values |
Object Definition: TASK (system object Task) Task Activity Item: ACTI_PRNT (Printing) Categories: None Custom Fields: None |
Java Qualifier: Checking System Field Values
public class VerifyingSystemFieldValues extends CustomCondition<Task> { @Override public boolean condition(Task task) { // Check whether the activity item of the task is Printing and the total amount of the task is greater than or equal to 10,000 return task.getActivityItem().equals("ACTI_PRNT") && task.getTotalAmount().doubleValue() >= 10000; } } |
Comparing Custom Field Values
Automated qualifiers are frequently used to compare field values. You can compare the values of any fields as long as the values are of the same data type. This example demonstrates how to compare the values from two custom fields of type Date.
Business Rule |
Served company records do not save if the values in the Service Date and Received Date custom fields are not the same. |
Qualifier |
Checks whether the date values are in two custom fields of the same type. |
Sample Values |
Object Definition: LITI (custom object Litigation) Categories: LITI (root category of Litigation) Custom Fields: ServiceDate (Date) ReceivedDate (Date) |
Java Qualifier: Comparing Custom Field Values
public class ComparingTwoCustomFieldValues extends CustomCondition<Project> { @Override public boolean condition(Project project) { // Getting the value of the service date field Date serviceDate = project.getDateFieldValue("LITI", "serviceDate");
// Getting the value of the received date field Date receivedDate = project.getDateFieldValue("LITI", "receivedDate");
// Return true if they are not equal return !serviceDate.equals(receivedDate); } } |
Checking Whether System Field Values Changed
Automated qualifiers in business rules often compare the values of a record that displayed when the record opened with the values entered by the currently logged-in user before saving the record.
The following sample checks whether the contact-centric field of a record has changed.
Business Rule |
Main policy holder cannot change in policy records without approval. |
Qualifier |
Checks the value on the screen in the Policy Holder contact-centric field against the value in the database. |
Sample Values |
Object Definition: Policy or any custom object definition Categories: None Custom Fields: None |
Java Qualifier: Checking Whether System Field Values Changed
public class CheckingWhetherRecordValuesWereChanged extends CustomCondition<Project> { @Override public boolean condition(Project project) { // Getting the object as it currently exists in the database - that is, the 'old' object Project initialProject = platform.getProjectService().readLastSaved(project);
// Return true if the contact associated with the project has been changed return project.getContact() != null && initialProject.getContact().getPrimaryKey() != project.getContact().getPrimaryKey(); } } |
Checking Whether Custom Field Values Changed
This sample demonstrates how to check whether the value in a custom field changed. Notice that the method of getting the database value and the value entered during the current session is done in the same as in the previous sample.
Business Rule |
Main policy holder cannot change in policy records without approval. |
Qualifier |
Checks the value on the screen in the Policy Holder custom field against the value in the database. |
Sample Values |
Object Definition: PLCY (custom object Policy) Categories: PLCY (root category of Policy) Custom Fields: PolicyHolder (Involved) |
Java Qualifier: Checking Whether Custom Field Values Changed
public class CheckingWhetherCustomFieldValuesWereChanged extends CustomCondition<Project> { @Override public boolean condition(Project project) { // Getting the object as it currently exists in the database - that is, the 'old' object Project initialProject = platform.getProjectService().readLastSaved(project);
// Getting new policy holder Involved currentPolicyHolder = project.getInvolvedFieldValue("PLCY", "PolicyHolder");
// Getting old policy holder Involved initialPolicyHolder = initialProject.getInvolvedFieldValue("PLCY", "PolicyHolder");
// Return true if the policy holder has been changed return currentPolicyHolder.getPrimaryKey() != initialPolicyHolder.getPrimaryKey(); } } |
Checking Roles in Related Records
You can use automated qualifiers to check the values in related records of the current object.
Business Rule |
No claim records can update if they do not have an involved record with the role Claimant. |
Qualifier |
Checks if an involved record has the specified role. |
Sample Values |
Object Definition: Policy or any custom object definition Related Object of Current Object: CLIN (Involved) Category in Related Object: CLIN_CLMT (Involved role Claimant) Custom Fields: None |
In the following sample, after getting the list of Involved records related to the current project object, the rule checks the list of categories (involved roles) added to each involved record. If a role does not exists, the qualifier returns true.
Java Qualifier: Checking Roles in Related Involved Records
public class CheckingValuesInRelatedRecords extends CustomCondition<Project> { @Override public boolean condition(Project project) { List<Involved> involvedList = platform.getProjectService().getInvolved(project); for (Involved involved : involvedList) { List<Category> roles = involved.getCategories(); for (Category role : roles) { if (role.getTreePosition().equals("CLIN_CLMT")) { // Return false if the project has any involved with the role of Claimant return false; } } } // Return true if the project has no involved with the role of Claimant return true; } } |
Checking Default Category in Related Records
The following sample gets the list of Involved records related to the current object and checks the default category (role) of each Involved record. If none of the Involved records have a particular category, the qualifier returns true.
Business Rule |
Claim records can only update if they have an Involved record with the role Claimant. |
Qualifier |
Checks if there is an Involved record with the specified role as its default role (category). |
Sample Values |
Object Definition: Claim or any custom object definition Related Object of Current Object: CLIN (Involved) Category in Related Object: CLIN_CLMT (Involved role Claimant) Custom Fields: None |
Java Qualifier: Checking the Default Role in Related Involved Records
package com.mitratech.teamconnect.enterprise.api.model.rule; import java.util.List; import com.mitratech.teamconnect.enterprise.api.model.Involved; import com.mitratech.teamconnect.enterprise.api.model.Project; import com.mitratech.teamconnect.enterprise.api.service.ProjectService; public class CheckingValuesInRelatedRecords2 extends CustomCondition<Project> { @Override public boolean condition(Project project) { // Getting the project service ProjectService projectService = platform.getProjectService(); // Getting the list of involved records related to the project List<Involved> involvedList = projectService.getInvolved(project); for (Involved involved : involvedList) { // If the default category is Claimant, return false if (involved.getPrimaryCategory().getTreePosition().equals("CLIN_CLMT")) { return false; } } return true; } } |
Checking Values in Vendor's Contact Record
The following qualifier checks whether the vendor of an invoice has a specific checkbox selected in the contact record. The qualifier then checks whether the number of line items in the invoice is more than the number that were in the previously saved version of the invoice.
Business Rule |
If the contact selected in the Vendor field of an invoice has the Volume Discount checkbox selected in the contact record, recalculate the task line item amount using the specified Discount Percentage field. |
Qualifier |
Checks the value in the Volume Discount checkbox in the contact record of the vendor. |
Sample Values |
Object Definition: INVC (system object Invoice) Related Object: CONT (system object Contact) Categories of Related Object: CONT_VNDR (category of Contact) Custom Fields of Related Object: volumeDiscount (checkbox) |
The following sample is an example of checking values in vendor's contact record.
Java Qualifier: Checking Values in Vendor's Contact Record
public class CheckingValueInVendorContactRecord extends CustomCondition<Invoice> { @Override public boolean condition(Invoice invoice) { // Get invoice service object InvoiceService invoiceService = platform.getInvoiceService();
// Getting old invoice object Invoice oldInvoice = invoiceService.readLastSaved(invoice); Contact vendor = invoice.getVendor();
// Return true if the vendor has volume discount set to true and the line item count on the invoice has increased return vendor.getBooleanFieldValue("CONT_VNDR", "volumeDiscount") && invoiceService.getLineItemCount(invoice) > invoiceService.getLineItemCount(oldInvoice); } } |
Checking Whether Custom Field Has a Value
The following qualifier checks whether a custom field that was previously null has a value, by comparing the value in the old object with the value in the current object.
This qualifier can be used with the action described in Creating Related Task Record.
Business Rule |
When the Trial Date field in a Matter updates with a value, create a task for the main assignee to complete the executive summary, with the due date 15 days before the trial date. |
Qualifier |
Checks the value in the Trial Date field in a matter record. |
Sample Values |
Object Definition: MATT (custom object Matter) Categories: MATT (root category of Matter) Custom Fields: trialDate (Date) |
Java Qualifier: Checking Whether Custom Field Has a Value
public class CreatingARelatedTaskRecordQualifier extends CustomCondition<Project> { @Override public boolean condition(Project project) { // Get old object Project oldProject = platform.getProjectService().read(project);
// Get current trial date CalendarDate trialDate = project.getCalendarDateFieldValue("MATT", "trialDate");
// Get old trial date CalendarDate oldTrialDate = project.getCalendarDateFieldValue("MATT", "trialDate");
// Return true if the current trial date is not null and the previous trial date was null return trialDate != null && oldTrialDate == null; } } |
