Billing EA38 transaction Parallel Processing Object Variants

[Former Member]

Hi,

We have a billing transaction EA38 which has parallel processing object and varaint on the technical settings tab.

We have 14 states for which we have to run the transaction in parallel. So we had set a parallel procesing object and a variant defining the intervals for all14 states.

But some of the jobs cancelled and only 6 states were processed successfully.

Then we changed the configuration to have a variant for each state on this technical settings tab.

Now the jobs are running sucessfully.

We are not sure what the issue was and whether this is a reliable solution.

Please guide me on this parlalel procesing object and its variants as to what exactly it does

Regards

[william_eastman]

maybe you are assigning functions to the parallel variant which do not exist.  The parallel processing variant describes the way that the system breaks up the full dataset (in this case - all billable billing orders) into groups for processing.  A parallel variant then will always represent the full dataset being broken up.  The individual EA38 selection criteria define which items from the full dataset are actually processed. 

Simple Example:

billing orders for installations 1-1000000 exist.  Odd numbered installations are for gas service, even numbered installations are for water service.

A parallel variant PAR1 is defined which breaks the dataset into 500 groups - installations 1-2000, 2001-4000, 4001-6000, etc.  all the way to the last group which is defined as 998001 - ZZZZZZZZZ (which for our case means 998001-1000000) since the dataset has to account for the full range of possible entries of the installation object. 

To bill the gas services, EA38 is set up with division criteria for gas - and parallel variant PAR1 is used.  The selection criteria ensures that only the gas objects are processed.  The parallel variant ensures that each job will process a limited subset of the total dataset.  In this case, each variant interval will process 1000 (the odd numbered installations) objects and then proceed to the next interval. 

The same happens when billing the water service- PAR1 is used but a different selection criteria is used. 

You can manually change the parallel variant - maybe to account for anomalies in the dataset eg the data is not uniformly distributed and the auto determination results in less than ideal distribution.  But it still must incorporate the full dataset 0-ZZZZZZZZ.  This is true for all parallel variants.

So to come back - parallel processes should only cancel when users try to execute them concurrently, when the system fails, or if there is some bad logic.  The parallel variant should not have any influence on that.

I would wonder why you need to process the states separately - and also why you need parallel variants for each.  Processing the states separately will result in longer overall runtimes for the batch process.  Individual variants will result in more maintenance.

regards,

bill.

[Former Member]

Thanks William for your reply..

But its strange that when we keep different parallel variants for each state our issue is resolved.

Strangely more we are not able to replicate the error by scheduling jobs for the data in quality.

It is only when the data runs in mass in night job this issue used to occur.

Now after maintianing the parallel variants separately we are not getting any error....

So as you said we are also not very much convinced how this issue is resolved by maintaining separate parallel variants..

So just wanted to have discussion in this forum.... Please let me know in case you can get any light on this from your collegues and friends..

Regards

[Former Member]

Did you check the application log to see why the jobs canclled.  The log or st22 would tell exactly why the jobs got cancelled.  Also do you have enough number ranges configured if you are running multiple jobs for EA38.