BPC75NW: Query on write-back BAdI

[PankajVPatil]

Hi,

I have a requirement wherein for 2 set of input schedules that are based on same APPSET and APPLICATION, have different ABAP logic to be built through write-back BAdI.

I try to built a second BAdI to put in the logic for second set of input schedules. But the resultant filter criteria comes out to be same as in the first write-back BAdI, which results in error during activation of object.

Possible solution: I will not be able to alter the filter criteria; but during run-time, is it possible to check the input schedule that invokes the write-back BadI, so I can put the IF at the start of logic to process either for first or second set of input schedules.

Regards,

Pankaj

[PankajVPatil]

Hi,

Posted the above query to another SDN thread.

Thanks,

Pankaj

[PankajVPatil]

Hi,

Can anyone please convey an applicable work around for the above scenario ?

Awaiting replies.

Regards,

Pankaj

[RichHeilman]

Yea, you have a tough situation here. There is nothing on the BAdI interface which is going to help you with this. The only thing you might be able to do is pull something out of the context, but it might have to be something like checking the current view for specific members. If the CV for each input schedule is different, you might be able to write your condition statement based on this. Use the static methods of class CL_UJ_CONTEXT to get the current view.

Cheers,

Rich Heilman

[PankajVPatil]

Hi Rich,

Thanks for the reply.

Currently as a work-around, I read CT_ARRAY, which has account dimension as a column.

The values coming in CT_ARRAY (for time-being) are different for the first and second set.

So I have written READ TABLE.. for certain values of first set and for certain other values for set 2.

I guess the CL_UJ_CONTEXT class will give me the information about members on current view, which is kind of similar to my current work-around.

Going ahead I anticipate to come across scenarios when the current view remains identical and we need to process the logic based on the input schedule that invokes the BAdI.

Anything identifying the source input schedule should be perfect.

Regards,

Pankaj

[PankajVPatil]

To add on to the above point, I have a certain logic that can be processed through write-back as well as custom logic BAdI (that can be called in default logic).

What will be the best place to put this logic, considering the following:

1) There are no additional LGF's getting called in default logic.

2) No intermediate COMMIT statements are embedded anywhere.

We can put filter in write-back to specify the execution only for input schedules, whereas Default will run after every Data save in the application.

The down-side of this is that I have to combine logic for all applicable input schedules into one write-back BAdI and separate it out based on the data that is coming in from CT_ARRAY.

Please let me know what should be the preference .

Thanks .