Retaining Source System Keys
Question Received: A customer has asked me if its possible to keep the original account numbers when migrating information across to CC&B. My thoughts are that it could be done by inserting the account numbers into the key tables manually and not letting the migration create the account numbers.
Whilst I think this is possible, I am going to steer the customer away from doing this because of the added risk to the migration process. I am however interested in your thoughts on this and if anyone has attempted it before?
Answer:
Whilst feasible to retain the old key values, it should be noted that the conversion effort would have to do a number of things to ensure that the old values are brought over:
1. All source keys must be unique numeric values.
2. Indentical values must be entered onto the CX_ID and CI_ID fields on tables traditionally populated by the KEYGEN conversion step (ie. all CK_* tables in the Staging Schema) (I recommend adding the same value to INIT_ID for completeness as part of this process).
This does open the application up to performance issues if the database tables have been partitioned, you may end up with all of your data stored in a single partition due to a potential mismatch between the original key lengths and the CC&B key lengths (instead of spread across the range as normally occurs via the CC&B KeyGen process).
We have attempted it in the past but dropped it due to the difficulty in completing the abovementioned components, but it is by no means impossible.
As an aside, it is possible to store the source account number in the SA.OLD_ACCT_ID or as a characteristic on the Account and use this as a search/matching value via some simple 2.1-related customisations. I have developed solutions in the past which allow us to use the existing source system identifiers in all of our external interfaces, whilst still allowing for new accounts to be added (these get assigned a 'new' external identifier in the same format as the source system values).
This identifier is then the only one presented to the customer on all communications, and is utilised in the incoming payment interfaces, But internally all records still use the basic CC&B key allocation routines.
Whilst I think this is possible, I am going to steer the customer away from doing this because of the added risk to the migration process. I am however interested in your thoughts on this and if anyone has attempted it before?
Answer:
Whilst feasible to retain the old key values, it should be noted that the conversion effort would have to do a number of things to ensure that the old values are brought over:
1. All source keys must be unique numeric values.
2. Indentical values must be entered onto the CX_ID and CI_ID fields on tables traditionally populated by the KEYGEN conversion step (ie. all CK_* tables in the Staging Schema) (I recommend adding the same value to INIT_ID for completeness as part of this process).
This does open the application up to performance issues if the database tables have been partitioned, you may end up with all of your data stored in a single partition due to a potential mismatch between the original key lengths and the CC&B key lengths (instead of spread across the range as normally occurs via the CC&B KeyGen process).
We have attempted it in the past but dropped it due to the difficulty in completing the abovementioned components, but it is by no means impossible.
As an aside, it is possible to store the source account number in the SA.OLD_ACCT_ID or as a characteristic on the Account and use this as a search/matching value via some simple 2.1-related customisations. I have developed solutions in the past which allow us to use the existing source system identifiers in all of our external interfaces, whilst still allowing for new accounts to be added (these get assigned a 'new' external identifier in the same format as the source system values).
This identifier is then the only one presented to the customer on all communications, and is utilised in the incoming payment interfaces, But internally all records still use the basic CC&B key allocation routines.
Comments