In this scenario, an event is caused by an account holder attempting to change his PIN number and incorrectly entering his current PIN number (see Figure 2). WBE ensures that if this “bad pin change” event occurs against the same account three times within a 24- hour period, then a “suspicious activity” action occurs. Upon receipt of a suspicious activity, two actions occur:
• A Web service request is sent to CICS to suspend the account.
• The account administrator receives an email with the account number of the potentially fraudulent activity.
The event source in this scenario is an existing CICS COBOL application that processes PIN change requests. This application is equipped with a few extra statements to cause an event to be emitted each time an incorrect original PIN is entered during a PIN change request.
COBOL statements are used to set up the containers that CICS will populate and send to a CB11-supplied program, EPSEMIT; one name-value pair that represents the details associated with the event is sent. The code fragment in Figure 3 places the name “Bad_ Pin_Change” into the correct container to name the event.
The single name-value pair containing the details of the event will contain the string “AccountNumber” and an account number of “1234567890” which is hard-coded as the value of the account number for this scenario. In reality, this data would come from a variable used in the program, probably on an EXEC CICS command. Figure 4 shows the code fragment that populates these containers. The SupportPac also needs information regarding on which WebSphere MQ queue to place the outgoing event. This example uses a local (TYPE(QLOCAL)) queue called EP. TEST.EMITQ. This and the code fragment that does the actual link to the SupportPac are shown in Figure 5.
Conversion: SupportPac Processing