Lights Out Analysis

When a registration results in an exception, after the exception group is created and all exceptions are inserted it will go through a Lights Out analysis.

The Lights Out analysis is a feature available only from GBDS version 5 onwards

An exception will be analyzed by Lights Out when:

• An exception group has all biometric treatments finished

  • In this case, the Lights Out analysis and treatment are synchronized with the treatment in the API.

• When a registration is finished in the GBDS Cluster, generates an exception and the exception group has BIOGRAPHIC target

  • In this case, the GBDS Cluster will mark the exception group as READY for Lights Out analysis in the column lights_out_status in gbds.exception_group and the analysis is done asynchronously in the API afterwards

  • The exception group may have one or more exceptions.

Lights Out thread

To analyze exception groups for Lights Out, the API will have a service thread that will run in the API classified as LEADER in the table gbds.apis when:

• gbds.lightsout.enabled is true

• And the exception groups are marked as READY in the column lights_out_status of the table gbds.exception_group

The API will behave as LEADER only if the configured hostname and port are equal to those described in the table gbds.apis

Lights Out Analysis

Given that the API classified as LEADER is running and an exception group marked as READY has been selected for analysis, the requirements for that group to be automatically treated are:

• The exception group must be an enrollment

• The exception group must not have key ID conflicts in its transactions (incoming included)

  • Keys configured in gbds.lightsout.enroll.unify.weakKeys are not considered

• The exception group must have matching biographic data across all its transactions (the biographic IDs are configurable)

  • The biographic keys that must match are configured in gbds.lightsout.enroll.unify.matchBiographics

  • For them to match, value and ID must be equal (accents are not distinguished in the value)

Lights Out Treatment

The group will be treated automatically once all the previous requirements are met

KEEP

The following will be kept:

• All transactions

• All keys

• All biographics of all transactions

  • If there is a conflict in biographic ID, the value from the last transaction will be kept

• All labels are included

• The treatment user will be lightsout

• The group treatment comment will be set to Lights out automatic treatment

The exception group will have the criterion used saved for future reference, which may be (nonConflitantKeys, weakKeys, matchedBiographics)

LightsOut lookup

The status of a Lights Out treatment can be queried from the Relational Database using the query:

To group the treatments by status

SELECT eg.lights_out_status, COUNT(*)
FROM gbds.exception_group eg
group by eg.lights_out_status;

To check a group individually, fetching the entire row via the GGUID:

SELECT * FROM gbds.exception_group eg WHERE eg.gguid = 'xxxx';

Reprocessing

To send an exception group for Lights Out analysis just change the group's status in the table gbds.exception_group using the query (changing the GGUID to the corresponding one):

UPDATE gbds.exception_group SET lights_out_status = 'READY' WHERE gguid = 'xxxx';

It is not recommended to change groups that have already been processed by AUTO_TREAT

Logout.

The Database settings for Lights Out are:

Configuration	Type	Default value	Description
gbds.lightsout.enabled	API	true	Value responsible for enabling Lights Out
gbds.lightsout.enroll.unify.weakKeys	API	-	Comma-separated list that defines the weak keys (will not be considered in key checking)
gbds.lightsout.enroll.unify.matchBiographics	API	-	Comma-separated list that defines which biographics must match key and value (accents are not considered)

API must be classified as LEADER in the table gbds.apis and must be active