Title
Mass Encrypting and Decrypting of Payment Cards

Purpose
The mass encrypting and decrypting of payment cards supports thefollowing scenarios:
If you have not used encryption for payment cards until now and youwould like to encrypt the payment cards currently maintained in thesystem, you can subsequently encrypt all the unencrypted payment cardswith this report.
If you are using a different, external report for encryption, you haveto decrypt all encrypted payment cards before installing the newproduct, because several external encryption products cannot beinstalled in parallel for the payment card master.
After you have successfully decrypted all payment card data, you caninstall the new security product. You can encrypt the existing paymentcards again when you have successfully installed the new product.
The performance of the encryption is greatly influenced by theinstalled external security product. The report is designed so that youcan carry out encryption or decryption for a number of payment cardsstated in the selection screen, and can schedule the report as a batchrun. The dialog recognizes whether a payment card is encrypted. Thus,not all payment cards have to be encrypted or decrypted for an event.
From the selection screen, you can carry out an analysis before theprogram start, to determine an expected runtime for the number of cardsstated. The prerequisites for the encryption or decryption are alsochecked.
Authorization and error-free encryption or decryption are included inthis. The entries in the selection screen are decisive here. If errorsare recognized here, that prevent this report being run throughsuccessfully, this is shown in the selection screen. These basic checksare always run through at the beginning of program execution as well.If errors occur, the report is terminated immediately, and you receivea corresponding message.
If you want to run through the report for all cards, then do not statethe number of cards.
If the report is scheduled in the batch run, errors can occur in theselection screen, despite an analysis. This can be the case, forexample if the analysis is carried out on an application server onwhich encryption or decryption is successful. A server should always beentered for the batch run, for which processing is carried out withoutany problems.
You receive a list with the following information:

• Card GUID as a unique key in the system


• Card type


• Error message which is filled when the encryption or decryption was not
successful for a card

• Previously encrypted value, which contains 000..... when encrypted, and
is filled during decryption

• Old card number


• New encrypted value, which is filled during encryption and is blank
during decryption

• New card number


• Cards, for which errors have occurred, are stated at the beginning of
the list
The error message then contains a note on the error that has occurred.
The list is output via the ALV (ABAP List Viewer). Correspondingly youyou can use the functions that are offered here. For example, you canenlarge the column for the error message via the layout so that you cansee the entire error text.
You can also save this list to a local file. This makes sense forexample, for securely saving the unencrypted card numbers in a fileoutside the system, during encryption. If the case occurs that a cardcannot subsequently be decrypted, you can determine the card numberfrom the local database via the GUID. However you should bear in mindthat numbers saved in a local file are saved as text and not asnumerical values, and you should bear in mind whether or not otherprograms can interpret them correctly.
The report can be carried out via the indicator 'test run' without thechanges being copied into the database. In this way you can test theprocedure in the test run before you start it in the update run.
You receive the list regardless of whether a test run or an update runis carried out.

Features