Stu's Braindump

I have been asked why I tend to avoid running the Tidy Balances Conversion process, and the short answer is that 'I have never found a need to..'. The Tidy Balances process has been designed to accept an input file of Accounts and balance 'buckets' and will produce adjustments of a specific type to ensure that the account has aged balances of these values. This could be handy in situations where minimal transaction data is being converted into CC&B via the traditional Extract-transform-and-load means (ie. convert all source data into CC&B Adjustments and Financial Transactions and run the required Validation and Keygen processes), it does not fit well with my experience of bringing 2-5 years of history over (which seems to be a common requirement on CC&B projects) and needing to create an opening balance for the Service agreements which is essentially just a placeholder transaction which is no longer subject to any aging or collection processing . The ef...

The attached image provides an overview of how the CC&B Conversion process hangs together. Hopefully this proves useful to you in understanding the various components of the process. For in-depth detail of the Server-side conversion modules, check the CC&B online help.

Hint: One of the questions that I tend to get asked a lot is... how do we speed up conversion? I tend to focus on a number of factors in an attempt to speed things up, but my top 11 is: Are the Staging and Production schemas on the same database/tablespace? Are the disks experiencing hotspots as a result of this shared implementation? If the two schemas are not on the same database, what is the theoretical maximum capacity of the link between the two instances? Is the machine CPU or Memory constrained? Can multithreaded runs be threaded further? Can Indexes be dropped for specific conversion steps? In most instances it it cheaper to drop the indexes before any mass insert steps and rebuild them afterwards than wear the cost of multiple I/Os for each insert. In instances where the indexes cannot be dropped, have these been created on their own database tablespace, with a dedicated I/O channel? For multi-threaded jobs, are the thread ranges reasonable, or can better results b...

All, Apologies for not updating this blog on a more regular basis. I am flat out at the moment on project related work, and neck deep in CC&B 2.2 updates, but I will attempt to post more regularly in the future. Once again, if you have any questions, feel free to post them here, or contact me on my email address.

Hint: I tend to expect my conversion effort to run for about 24-36 hours all up (assuming the machine has been spec'ed to suit the customers implementation footprint and standard batch schedule expectations). This tends to include the migration to Prod, and Tidy Balances (including database backups at various stages throughout the process). As a rule of thumb though I tend to break the processing down to: ~10-20% - Input Transform (ie ConversionCentral) ~25-30% - Object Validation ~ 5-10% - Key Generation ~ 5-10% - Tidy Balances ~10-15% - Production Migration ~15-25% - Reporting

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 co...

Hint: I have noticed that running a single instance of the Conversion validation runs on a Windows box results in massive under-utilisation of CPU, RAM and I/O. My recommendation is that all runs of these jobs be run in threaded mode (I tend to start with 2 threads per CPU and assess the performance from that point). Some work has been done on rewriting the batch submission scripts for both Unix and Windows to support easier multi-thread submission and the auto-processing of batch parameters. Let me know if you would like more info.