Content

Case consolidation: Behavior across versions and impact on upgrade

This technical note explains how the behavior of case consolidation has changed over time and the impact that has on how cases are handled after a version upgrade.

Case consolidation before version 6.5.0.00

In versions of IBM Safer Payments before 6.5.0.00 case consolidation was triggered by selecting an Aggregation attribute. All cases with the same value of the Aggregation attribute were consolidated together, even if they were from different case classes.

In version 6.5.0.00, Case aggregation conditions were added. They  allow for more control over how aggregation is done. When an upgrade is done from a version before 6.5.0.00 to a version after 6.5.0.00, the Aggregation attribute is automatically converted to new Case aggregation conditions.

However, the conversion that is automatically done by an upgrade has been changed depending on the fixpack version that you are upgrading to. In versions 6.5.0.07, 6.6.0.05, and 6.7.0.02 the upgrade logic was changed so that the behavior after the upgrade more closely matched the behavior prior to the upgrade. The differences are explained below.

Examples

Say you have three case classes, Class1, Class2, and Class3. In all the case classes you will select two reporting attributes: “Primary Account Number” (PAN) and “Merchant Terminal Number” (MTN).

In versions before 6.5.0.00, you select an Aggregation attribute in order to do consolidation. Let’s say that in Class1 and Class3 you select PAN as the Aggregation attribute, and in Class2 you select MTN as the Aggregation attribute.

Example 1:

Now let’s say that three transactions come into the system, all of which create cases.

Transaction 1 has a PAN of 1111-1111 and an MTN of 12345, and an alarm gets added to Class1

Transaction 2 has a PAN of 1111-1111 and an MTN of 12345, and an alarm gets added to Class2

Transaction 3 has a PAN of 1111-1111 and an MTN of 12345, and an alarm gets added to Class3

In versions before 6.5.0.00,  transactions 1 and 3 will be consolidated into the same case. However, transaction 2 will not be consolidated and will be in its own case.

Transaction 2 is not consolidated because transaction 2 was added to Class2, and Class2 has MTN as the aggregation attribute. Although the other alarms also have the same value for MTN (12345), since they are added to case classes that use a different aggregation attribute, they will not aggregate with transaction 2, because alarms with different aggregation attributes are not aggregated together.

However, Transaction 1 and 3 are consolidated together even though they are from different case classes because their case classes share the same Aggregation attribute.

Example 2:

Now, let’s say that you have two cases that are manually created.

A user creates a case manually for Class1 with no value set for the PAN, but a value of 98765 for the MTN.

Another user creates a case manually for Class3 with no value set for the PAN, but a value of 98765 for the MTN.

In versions before 6.5.0.00, these cases will not be consolidated together because the PAN attribute is empty, and cases with empty PAN attributes are not consolidated together.

Case consolidation in version 6.5.0.00 and higher

Now, let’s consider the behavior after an upgrade to 6.5.0.00 or higher.

When upgrading to version 6.5.0.00 or higher, the Aggregation attribute is converted automatically to Case aggregation conditions. The conditions that are automatically created depend on the exact version that you upgrade to.

When upgrading to a version from 6.5.0.00 through 6.5.0.07, or 6.6.0.00 through 6.6.0.05, or 6.7.0.00 or 6.7.0.01, a single condition will be created, [Aggregation attribute] equal to [Aggregation attribute]. We will call this behavior Upgrade behavior 1.

When upgrading to a version of 6.5.x higher than 6.5.0.07, or a version of 6.6.x higher than 6.6.0.05, or a version of 6.7.x higher than 6.7.0.01,  three conditions will be created:

• [Aggregation attribute] equal to [Aggregation attribute]
• [Aggregation attribute] is not empty
• [CaseClassId] equal to [CaseClassId]

We will call this behavior Upgrade behavior 2.

Now we will examine the case consolidation results on a system that has gone through the different upgrade behaviors.

Upgrade behavior 1 examples

After an upgrade to a version with Upgrade behavior 1, Class1 will have a single Aggregation condition of [Primary Account Number] equal to [Primary Account Number].
 

Class2 will have a single Aggregation condition of [Merchant Terminal Number] equal to [Merchant Terminal Number].
 

Class3 will have a single Aggregation condition of [Primary Account Number] equal to [Primary Account Number].

Example 1:

Using the same transactions as before, we will end up with all three transactions consolidating into the same case.

This occurs because there is only a single condition that is checked when aggregating new alarms into existing cases. It will check if the PAN of the new alarm is equal to the PAN of the case, and it will consolidate the alarm into the case.

Since this behavior is usually not desired, the upgrade behavior was changed in later versions.

Example 2:

Using the same example as before, both manually created cases would now be consolidated together. This is because the PAN is equal between the two cases, even though it is empty.

Since this behavior is usually not desired, the upgrade behavior was changed in later versions.

Upgrade behavior 2 examples

After an upgrade to a version with Upgrade behavior 2, Class1 will have three Aggregation conditions of [Primary Account Number] equal to [Primary Account Number], [Primary Account Number] is not empty, and [CaseClassId] equal to [CaseClassId].
 

Class2 will have three Aggregation conditions of [Merchant Terminal Number] equal to [Merchant Terminal Number], [Merchant Terminal Number] is not empty, and [CaseClassId] equal to [CaseClassId].
 

Class3 will have three Aggregation conditions of [Primary Account Number] equal to [Primary Account Number], [Primary Account Number] is not empty, and [CaseClassId] equal to [CaseClassId].

Example 1:

Using the same transactions as before, we will end up with three cases being created, with no consolidation happening between them.

Note that this is different than the behavior before 6.5.0.00, when transaction 1 + 3 would be consolidated into the same case. However, this was usually not desired so the default behavior was changed. If it is desired to have these cases consolidate together, then that can be achieved by removing the [CaseClassId] equal to [CaseClassId] condition from Class1 and Class3. After CaseClassId == CaseClassId is removed from case 1 and 3, not only alarm 3 but also alarm 2 can be consolidated into them.

Example 2:

Using the same example as before, we end up with two separate cases being created, with no consolidation, the same as before 6.5.0.00

Upgrading from Upgrade behavior 1 to Upgrade behavior 2

It is important to note that when you upgrade from a version with Upgrade behavior 1 to a version with Upgrade behavior 2, your conditions are not updated automatically. In that case you need to manually add the extra conditions to your case classes if you want the change in behavior. You can also update your conditions before upgrading to a version with Upgrade behavior 2, while you are still on a version with Upgrade behavior 1.