How to skip_record in tranformations after checking all datafields?

[Former Member]

Hello SAP BW Experts,

I need your help.

I would like to check all fields of a record in the transfer rule to fulfill the plausibility. I want to do it in the transfer rule separately 1:1 for every field.

In the case that some plausibility checks fails the record should transferred into the error stack with error messages for all failed checks.

For all record fields which not fulfill the plausibility requirements the exception 'skip record' (raise exception type CX_RSROUT_SKIP_RECORD) should raise just once.

So, the error stack is filled with one record with all of his wrong fields.

I want to avoid the problem, that the error handling in the transformation rule just checks one field of the record. Then, raise the 'skip record' and do not check the other fields of the record anymore.

The question is how to raise the exception type CX_RSROUT_SKIP_RECORD at the end of processing all transfer rules to fill the error stack, because the exception is not available in the start and end routine.

Kind regards, Stephan

[Former Member · Accepted solution]

Hi Stefan,

One question upfront, why are you not looping in the startroutine for every field. Makes things easier.

Here is the coding

monitor_rec-msgid = 'ZMY_BI'.

monitor_rec-msgty = 'E'. <-- Important, E stands for Error and will be moved to errostack

monitor_rec-msgno = '001'.

monitor_rec-msgv1 = l_err_msgv1. <-- your messages

monitor_rec-msgv2 = l_err_msgv2.

monitor_rec-msgv3 = l_err_msgv3.

monitor_rec-msgv4 = l_err_msgv4.

monitor_rec-skipped = 'X'. <-- you do not need to raise additionally - skip record

monitor_rec-recno = l_recno. <-- very important as the monitor expect a record number, always

delete result_package <-- BUT you need to delete the wrong record from the source package

Please consider the following

If you put a record to the error stack , brothers with teh same key should be considered as well.

This approach only works for DSO (overwrite) which needs a sequence in loading the data. the reason is that after the start routine coding, SAP is taking the semantic key from your DTP Settings (this is important) to find the brother's records with the same key and moves them automatically to the error stack as well as for all upcoming loads - as long as you do not empty the error stack by correcting the value and move foward by using the error dtp.

For cubes the brothers finding wont work as no sequence is expected.

Lets look at the coding and why this happened:

take your generated programm from the trfn

Search for the breakpoint after the startroutine (means your start routine coding is before)

find some lines below CALL METHOD i_r_log->verify_record

than p_r_errorlog->verify

in Verify you'll will see CHECK p_serialized = 'X'. (this is a standard DSO only)

I couldn't find yet where this is taken from... but if someone has time to look at, let me know.

If X is not set not brother finding wont be considered.

This coding doesn't exist in the end routine, so no brother finding here. A trick to enforce it (when you need to have some error messages in the end routine) is using two infosource in between of your target standard DSO and your source than you need three TRFNs and you could use the first end routine for your error handling and the second start routine (second trfn) automatically checks the verify->records again. Thats nice as the dtp is working from source to target independent of teh TRFNs in between.

Now lets go back to the generate programm, as you can see after the verify->records call

you will find the local rule coding. That means brother finding only works for the start routine not in the local rules.

Hope that helps.

[Former Member]

Hi,

Isn't it easier and faster to do the fields plausibility check at source_package level in start routine ?

the CX_RSROUT_SKIP_RECORD is available at this level.

regards.

Raed

[Former Member]

Hi Raed,

the problem is, that the skip_record exception to fill the error stack is not available in the start and end routine. There is only the exception 'cx_rsrout_abort' available.

start_routine

IMPORTING

request type rsrequest

datapackid type rsdatapid

EXPORTING

monitor type rstr_ty_t_monitors

CHANGING

SOURCE_PACKAGE type tyt_SC_1

RAISING

cx_rsrout_abort.

Have you got an idea how to raise it anyhow after checking all field of the record?

Best regards, Stephan

[Former Member]

Hi stephan,

I suggest u to add a new (physical) infoobject into your source object structure; lets call it 'flag'.

In the start_routine loop at your source_package and do all the plausibility checks for the fields; if result is not okay then insert 'X' in the flag zone and update the source_field.

Then in the transformation fields level, insert a routine only for 'flag' field and check if the field 'flag = 'X' then do a CX_RSROUT_SKIP_RECORD.

this can work but may slow the load performance.

Hope it helps

Raed

[Former Member]

Hi Stephan,

What about doing the following.

• Create a global counter to track the number of field routines executed.

• Create a global table to track all errors.

• In each field routine write an if statement to check if last field routine is executed.

Example, if you have 14 fields routines.

gv_ctr = gv_ctr + 1.

if error in field.

add error into gv_errtable.

endif.

If gv_ctr = 14.

Create error message

Raise skip record exception.

gv_ctr = 0.

Endif.

you can also look at the generated program and find the last field routine exectued an only rasie the exception there.

Regards,

Dae Jin

Edited by: Dae Jin Swope on Jul 19, 2010 10:40 AM

[Former Member]

Hi Raed,

thank you for your suggestion. It sounds very good, by doing the field check in the start routine. The problem is, the BW Admin wants to see directly in the transfer rules which field is affected by the plausibly check. Therefore I need a method to create monitor entries for all error fields first and send the error record then to the error stack in the transfer rule. It would be very grateful, when you have got an idea.

Stephan

[Former Member]

Hi Stephan,

fulfilling your requirement should be possible by adding a method or function module to one of the characteristic routines. Pass the complete record to that method or fm as well as the monitor table, do your checks for each field of the record and add a monitor record for each incorrect field. At the end of the method or fm you set a additional return value to 0, in case everything was ok, or to 4, in case a error record was added to the monitor table. Back to the field routine, check that return code and in case of NE 0, raise the exception.

regards

Siggi

[Former Member]

I think what stephan needs is one Skip_record exception that group (detail) all the errored fields of a source line.

if so, i'm not sure it's possible unless finding a way to send a message line along while sending the raise_exception_skip..

maybe the experts have some ideas .

regards

Raed

[Former Member]

Hi Guys,

thank you for your good answers! Raed exactly described my requirements which could be solved by your suggestions.

I tried first the method of 'Raed' to mark the record with the error fields in the start routine and raise skip_record in transformations. The result is, that the record is skipped but it is not transferred to the error stack, because it seems to need an error message type "E" in the monitor. But if so, the error message from the start routine is overwritten.

The second method of u2018Siggiu2019 sounds good but it fulfill not the requirements of the admin to visible all affected characteristics in the transfer rule.

The third method of u2018Dae Jinu2019 is my preferred one. I like the suggestion in combination of u2018Siggi´su2019 method to create a function module/ method for every field of the record in the transfer rule. Each one should check a global counter and raise the exception (If gv_ctr = 14.).

If gv_ctr = 14.

Create error message

Raise skip record exception.

gv_ctr = 0.

Endif.

The last problem it solve is, how to say dynamical the function module/ method to raise the exception in the last routine (here: 14), without giving the function module the parameter 14 p.a.?

How can I realize the second suggestion of u2018Dae Jinu2019??

"You can also look at the generated program and find the last field routine executed and only raise the exception there".

Best regards,

Stephan

[Former Member]

Stephan,

In a transformation, every field routine is represented by a method call. You can see this by looking at the generated program. You can get to the generated program by menu path "Extras-Display Generated Program" in the "Transformation Display" screen.

Each field in the transformation is represented by the following comment:

*<<< Rule ID: '50'.

You will want to look for Type 'ROUTINE'. Something like this

*<<< Rule ID: '51'.

IF lssupp-_51 EQ rs_c_false.

currrule-ruleid = '51'.

• Step ID: '1', Type: 'ROUTINE'.

currrule-stepid = '1'.

CLEAR: ltmsg,

G1-/BIC/ZKPI1.

The last one listed in the program would be executed last. Do a search for the following line of code.

"CATCH cx_rsrout_skip_record INTO lr_cx_root."

From here, work your way up the code looking for the last Rule ID with type ROUTINE that is one of your 14 checks.

Pre-requisite: You will need to have each of these 14 fields mapped with type routine.

I still think the better approach is to include this code in each of the 14 fields routines.

gv_ctr = gv_ctr + 1.

Do error check.

if error in field.

wa_err-num = #.

wa_err-msg = msg

append wa_err into it_err.

clear wa_err.

endif.

If gv_ctr = 14.

If not it_err is initial.

loop at it_err into wa_err.

monitor_rec-msgty = 'E'.

monitor_rec-msgno = wa_err-num.

monitor_rec-msgv1 = wa_err-msg.

APPEND monitor_rec TO MONITOR.

clear wa_err.

endloop.

RAISE EXCEPTION TYPE CX_RSROUT_SKIP_RECORD

endif.

clear it_err.

gv_ctr = 0.

Endif

Regards,

Dae Jin