I have moved my blog back within the Oracle blog-space. please update your links and RSS feeds to point to my new home at http://blogs.oracle.com/stusbraindump
My current project contained a requirement to embed an external application within the the CC&B framework and initiate calls to this application supplying a number of context elements to ensure that the correct information is displayed. The client also requested that the application be 'skinned' to maintain the CC&B look-and-feel. This is how we implemented it.. Defined a number of Business Object to manage retrieval of data from some of the base CC&B objects in a flattened format (ie. Characteristics mapped to descriptive elements, unused fields not defined, etc). Defined a UI map which forms the canvas for 'painting' the application within our framework. A Query Zone to ensure that the required data associated with the Context Zones are retrieved (using Zone type F1-DE-QUERY). A Business Service to wrap the call to the Query Zone into a usable service. A Script to initiate the call to the Business Service with the associated Context Identifiers (fr...
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...
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.
Comments