DESTINATION_APP writes on source app but not at destination app

[former_member295530]

Hi experts.

I'm having a trouble with a custom logic BADI-calling to write data from one application (CONS) to another one (ADQU).

I'm working in the following environment:

Komponente	Release	SP-Level	Support Package	SPP-Level	Support Package Patch
SAP_BW	740	0005	SAPKW74005	0000	-	SAP Business Warehouse
CPMBPC	801	0006	SAPK-80106INCPMBPC	0000	-	CPM Business Planning and Consolidation

I have the following code at Script-Logic:

*DESTINATION_APP = ADQU

*SKIP_DIM = C_GROUPS

*RENAME_DIM C_ACCOUNT = A_ACCOUNT

*RENAME_DIM C_CATEGORY = A_CATEGORY

*RENAME_DIM C_ENTITY = A_ENTITY

*RENAME_DIM C_INTERCO = A_INTERCO

*RENAME_DIM C_DATASRC = P_DATASRC

*RENAME_DIM C_FLOW = P_FLOW

*RENAME_DIM C_CURRENCY = P_INPUTCURRENCY

*RENAME_DIM C_TIME = P_TIME

*START_BADI ZFCON_T_AD

PERIOD=2013.APR

LOGICA=T_AD

ENTITY=0175

QUERY = ON

WRITE = ON

*END_BADI

*COMMIT

When I test this code with UJKT tx. the new data are written in the source APP (CONS) instead of "ADQU", the target app.

When I debug the BADI and I can verify that just before exit it the CT_DATA table has the correct data, but they are written at "CONS" APP as i mentioned before.

Please, anyone can help with this issue.

I would be very grateful.

Thanks in advance.

Raúl Rozalén

[former_member295530 · Accepted solution]

Hi All, Hi Andrea...

Sorry for reply so much time after my last post.

Only a few lines to comment about the solution which was achieved using the tips that Andrea linked in his last answer.

We use CUSTOM_LOGIC BAdI that must be called from Script Logic with parameters WRITE=OFF and QUERY=ON... After data transformation we have a CT_DATA table with the data that we want to write at ADQU model and then:

* lt_write_back_adq is defined as an structured type with the same fields tha ADQU model

     create data wb_data   type standard table of lt_write_back_adq with non-unique default key.

     assign wb_data->*   to <td_write_back>.

     create data wb_errors type standard table of lt_write_back_adq with non-unique default key.

     assign wb_errors->* to <td_write_back_err>.

* we pass data from CONS model structure to ADQU model structure                                            

     loop at ct_data assigning <ls_ct_data>.

       assign_component: lf_c_account  <lv_c_account>,  lf_c_time     <lv_c_time>,    ...

       ...

       clear ll_write_back_adq.

       ll_write_back_adq-a_account       = <lv_c_account>.

       ll_write_back_adq-p_time          = <lv_c_time>.

       ...

       assign ll_write_back_adq to <ld_write_back>.

       insert <ld_write_back> into table <td_write_back>.

     endloop.

* lo_ujo_write_back type ref to cl_ujo_write_back

     create object lo_ujo_write_back.

     move appset_id to l_appset_id.

     move appl_id   to l_appl_id.

     try.

       call method lo_ujo_write_back->if_ujo_write_back~write_back

         exporting

           i_appset_id      = l_appset_id

           i_appl_id        = l_appl_id

           it_records       = <td_write_back>

         importing

           et_error_records = <td_write_back_err>

           et_message       = lt_message

           ef_success       = lf_success

           et_message_df    = lt_message_df.

       catch cx_ujo_write_back .

       catch cx_uj_static_check .

     endtry.

* Here we have a block in which we check the content of importing parameters and the content

* of <td_write_back> in order to fill in the message table that is returned to script logic

* at the end of the BAdI process to display this info in the log of the logic after its execution

     ...

     ...

     ...

I hope this can be usefull for other collegues.

Thanks a lot.

Raul R.

[Former Member · Accepted solution]

Hi Raul

thanks to share your solution.

Best wishes

Andrea

[Former Member]

Hi Raul,

I think that the BADI doesn't recognise the command DESTINATION_APP.

Please take a look at this link *DESTINATION_APP - SAP Business Planning and Consolidation, version for SAP NetWeaver - SAP Library

It explains you how the command works.

Otherwise you can replicate the same functionality in your BADI

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/e04b5d24-085f-2c10-d5a2-c1153a9f9...

Hope this can solve your issue

Regards

Andrea

[former_member295530]

Hi Andrea.

First of all, thanks for your answer.

Unfortunately the solutions that you mention are not valid for us.

We had checked both links before posting this thread.

The first one does not provide us additional info about DESTINATION_APP command that would help us with our problem

With the second one. We had incorporated the objects that are contained in the order files attached with the document in our systems , but the objects have had syntax errors and after this point we could verify that this solution does not apply in the release in which we are working.

We think that we can take a workaround if the BAdI sets a controlled value into a field and after the START_BADI ... END_BADI we verify that value, and write with FACTOR=1 at ADQU APP, but we need to avoid that the BAdI process itself writes data into source APP (CONS) and that point we are not being able to achieve it.

*DESTINATION_APP = ADQU

*SKIP_DIM = C_GROUPS

*RENAME_DIM C_ACCOUNT = A_ACCOUNT

*RENAME_DIM C_CATEGORY = A_CATEGORY

*RENAME_DIM C_ENTITY = A_ENTITY

*RENAME_DIM C_INTERCO = A_INTERCO

*RENAME_DIM C_DATASRC = P_DATASRC

*RENAME_DIM C_FLOW = P_FLOW

*RENAME_DIM C_CURRENCY = P_INPUTCURRENCY

*RENAME_DIM C_TIME = P_TIME

*START_BADI ZFCON_T_AD

PERIOD=2013.APR

LOGICA=T_AD

ENTITY=0175

QUERY = ON

WRITE = ON

*END_BADI

// This part is about the workaround mentioned in the answer text

*WHEN C_DATASRC

*IS BADI                                                                       //This is the controlled value to check

*REC(FACTOR=1,C_DATASRC=INPUT)

*ENDWHEN

*COMMIT

With this solution we have checked that data are written in target APP (great!!!) but also is still writing in source APP and we need to avoid it.

So, if you or anyone else can help us knowing this aditional info, we would be very gratefull.

Thanks in advance.

Raúl Rozalén

[Former Member]

Hi Raul,

you're welcome.

I think that in your soultion the BADI writes data in the datasrc BADI in the app CONS and the DESTINATION_APP writes in ADQU when the datasrc is BADI.

For this reason you can still find data in the app CONS.

I think that the link provided was for the release 7. Try to have a look here. Maybe it could be useful http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/702bf959-c89a-3010-aeb0-b43a4bfd8...

Also those links can be useful

http://scn.sap.com/thread/3377931

Could you please explain what you need to push in the second model? What kind of info do you need about the command DESTINATION_APP? Maybe it's possible to find a solution .

What you can do is a normal script logic (with a different destination), then if you need special calculations you need to use a BADI but share your need before.

Regards

Andrea

[former_member295530]

Hi Andrea.

As you mentioned, with our last approach we write data at Source APP with datasrc = BADI, and after returning from BADI processing, the script logic writes data in the Target APP when datasrc = BADI.

We want to avoid the first "write" in the Source Model.

We have been reviewing the links that you pass in your second reply and we think that maybe the use of write_back method could help us, but here we have another question.

We have implemented our CUSTOM_LOGIC BADI and the question is if we have to call write_back method in the BADI code (just before ending BADI processing) or if we have to replicate the code that we have at CUSTOM_LOGIC in another BADI for CL_UJR_WRITE_BACK.

What we need to do is take data from Source Model and write them into Target Model after some calculations that are made if some conditions match.

Regards.

Raúl Rozalén.