UJ_VALIDATION Badi - Read Master Data only once

[former_member296894]

Hello,

I have implemented data input validations (for manual input and journals), I first tried with the Write-Back Badi, but then realised that the UJ_VALIDATION would have been a better option, because it gets executed on journal saves). I have implemented both solutions (sequence of checks are identical and I realised that on larger data sends (couple of thousands of records), there was a huge performance difference between the two approaches, the write-back Badi is performing much better (this comment is of course only valid for manual input, not an issue for journals)

My validation are based on properties, so I need to read couple of properties from 6 different dimensions and then perform my validations. In the write-back Badi, I read out all the master data once and then loop through the ct_array table and perform my checks.

But in UJ_VALIDATION Badi, I need to read the master data individually for each record in the IS_DATA table (I of course only need the specific record I need, not the whole table like in the Write-back Badi). Is there a way to centrally read all the master data at the beginning of the validation process (put it in internal hash tables) and then look it for each IS_DATA instead of reading it separately for each record ?

Regards,

Marcel

[former_member186338 · Accepted solution]

Hi Marcel,

You performance issue is due to the fact that write back badi receives all changed/inserted records at once in one table and the validation badi is executed by single record. I recommend you to use write back badi. It's working also with data posted by journals.

Vadim

P.S. What do you mean by "validation process"? Validation is done record after record individually...

Message was edited by: Vadim Kalinin P.S. added

[former_member296894 · Accepted solution]

Hi Vadim,

The validation are done row by row, but the Write-back code only get executed when a journal is acutally posted, not when it is saved (which is much better for end-users)

I guess I will have to stay with the current solutions, using the UJ_VALIDATION for the journal module and the Write-back for data input. I do however have to to duplicate some coding, which I would have preferred to avoid (coding for checks is already in a helper class), but the master data read (only for current record vs. all master data) and data processsing (only current records vs. looping through a table) are different

Regards,

Marcel

[former_member186338 · Accepted solution]

For journals look on BADI_UJJ_CALCULATED_AMOUNT, may be you can do something in this badi. In BPC 7.5 we have developed enhancement to the standard BPC code to perform checks and rounding of journal records...

B.R. Vadim

[former_member296894 · Accepted solution]

Hi Vadim,

I considered that Badi, but I believe that it can only be uses to generate additional records, I do anything on the existing ones.

I will go for the write-back part on the Manual Data Input, but I cannot find a proper solution for the journal module. I have noticed that UJ_VALIDATION Badi gets when the default logic posts data (which I don't want, as I want to post records to combinations not allowed on input), is there a way to avoid having UJ_VALIDATION executed after default logic ? This causes be problems with my journal.lgf logic...

I have not activated UJ_VALIDATION for Data Manager, so I was not expecting the default logic records to be processed in UJ_VALIDATION

Regards,

Marcel

[former_member186338 · Accepted solution]

Hi Marcel,

As far as I remember with write back it was possible to distinguish between data originally sent by input schedule and the data generated by default.lgf (we have validation in write back - it's prohibited to write directly to some members, but default.lgf can write). Never tested it with validation badi. Look on write back incoming parameters - may be it will help you with validation.

Vadim

[former_member296894 · Accepted solution]

Hi Vadim,

Thank you for all the input. There is a parameter on the write-back that indicates whether the send records are processed or the ones generated by the default logic. This input parameter is unfortunately missing for the UJ_VALIDATION badi.

Regards,

Marcel

[former_member186338 · Accepted solution]

Enhancement is always an option

Vadim

[former_member296894 · Accepted solution]

I finally found a solution to do what I wanted in the first place.

I use the CLASS_CONSTRUCTOR method to read all my master data (class constructor is only called once for all the validations) and store them in CLASS level variables.

To distinguish between the first execution of the UJ_VALIDATION BADI and subsequent calls from the Script Logic, I check the content of the ABAP CallStack. It's not a perfect solution, but it seems to work well.

[former_member186338 · Accepted solution]

What about performance increase?

And what happens if master data is updated?

Vadim

[former_member296894 · Accepted solution]

It does get executed one time on each data send , so there is no problem with master data updates

[Former Member]

Even the UJ_CUSTOM_LOGIC does not have the parameter to find the source of the call whether its called from DM or input schedule. But I used the static attribute g_module_id of class cl_ujk_model (cl_ujk_model=>g_module_id) which has the values DM or MAN to identify the source call. I guess, the value should be JRN for Journals but I have never tested the validation BAdI though.

-Prabhu

[former_member296894]

Hi Prabhu,

Thank you for that suggestion. I will try it. I ended up using cl_uj_context=>get_current_context to get the module name and the transform it to the Module ID (like "MAN", "JRN")

Regards,

Marcel