Synchronise Accounts

-
The Synchronise Account functionality has been available in CC&B for quite a while now, and whilst we tend to shy away from using it, it has its place in environment management.

With the recent performance fixes implemented on FW2.2, in regards to the CLBDSYNC module, this functionality now allows us to transfer subsets of records between environments in a quick and timely manner.

Whilst it is not designed to be used for large sets of data, it does allow us to pull records from our PROD copy instance back into the Pre-Prod environments to provide a basis for problem investigation.

Definitely something for you to investigate/consider as part of your on-going environment management effort.

Comments

Post a Comment

Popular posts from this blog

Bundle Corrections.

-
We have identified an issue with the use of bundling and UI Maps, whereby the resulting Bundle was wrapping the UI Map in a set of CDATA tags, but only after it had already removed all formatting from the source records, resulting in corruption of the UI Map HTML fragments. This has now been corrected by implementing Single Fix 8228025 on FW/CC&B 2.2.0. If you are using the Bundling subsystem in your implementation, I strongly recommend that you implement this patch.
Read more

Database Upgrades and their impact on Conversion

-
Hint: It appears that the current strategy in relation to application of Single Fixes and Service Packs no longer supports application of these scripts against a staging schema (at least as part of CC&B 2.x.x). As a result it is recommended that you drop and rebuild the Conversion schema from the Production instance once this has been upgraded with the latest patch-sets. We have also noted that application of these single fixes may require a redelivery of all custom java code from the development environment, since the java compilation is not performed as part of the patch install process (unlike the Cobol implementation process).
Read more

Threading...

-
A common question that I get asked is.. how do we force multi-threaded conversion jobs to split the key ranges evenly across each thread instance? Unfortunately I don't have an easy answer. The base conversion jobs seem to take a simplistic approach of using the low and high override values (if supplied, otherwise they use values of 0000000000 and 9999999999) and then divide these by the number of threads to determine the ranges for each instance. But.. We have found that we can force a predefined range of values and simulate threading but having separate batch controls defined for each thread, with predefined high/low values and these can then be run concurrently through standard batch submission processes.. e.g.. if we want to run VAL-ACCT in 4 threads and ensure that a known range of source keys between 0000000001 and 0000100000 is split between the 4 threads, we clone the existing batch control into VAL-ACCT1, with OVRD-LOW-ID = 0000000001 and OVRD-HIGH-ID = 0000025000 V
Read more