Intercepting Error Messages within external Subroutine calls

[Private_Member_7726]

Hi,

Is creating a "facade" Function Module wrapping external Subroutine call and then calling Facade using EXCEPTIONS error_message = xx Addition presently still the one and only way to "intercept" error messages issued by externally called Subroutines? Or is there another way (a trick, so to speak...) that does not necessitate creation of Function Module?

The context is: attempt to wrap valuable "SAP logic", virtually inextricably, but competently and diligently (reasonable degree of code modularisation; direct use of global state minimized; very little code directly in PBO/PAI modules, parameters used in Subroutines extensively, even dialog suppression enabled here and there) tied to DYNPROs, so assume the "external functionality" can not be refactored or copied (potentially opens even bigger can of worms in terms of maintenance).

Thanks,
Janis

[Private_Member_7726]

Hi,

Is creating a "facade" Function Module wrapping external Subroutine call and then calling Facade using EXCEPTIONS error_message = xx Addition presently still the one and only way to "intercept" error messages issued by externally called Subroutines? Or is there another way (a trick, so to speak...) that does not necessitate creation of Function Module?

The context is: attempt to wrap valuable "SAP logic", virtually inextricably, but competently and diligently (reasonable degree of code modularisation; direct use of global state minimized; very little code directly in PBO/PAI modules, parameters used in Subroutines extensively, even dialog suppression enabled here and there) tied to DYNPROs, so assume the "external functionality" can not be refactored or copied (potentially opens even bigger can of worms in terms of maintenance).

Thanks,
Janis

[Sandra_Rossi]

I don't know another efficient "trick". Or does Batch Input suit you? 🙂

Anyway, it's just to create one little function module by application, with a callback object parameter so that you can execute what you want behind the facade.

[Private_Member_7726]

I'm looking at... like some 18 FM, just to wrap logic containing input validations for the table control of «main screen» :) This:

and another input-validation-&-state-modification subroutine presents particular challenge, because it, for some weird (meaning, unknown to me thus far) reason, grabs the current table control line directly from global Function Group state TC declaration, rather than having in passed down from PAI module like most other INPUT subroutines requiring current TC line... But there is arcane way I could "control" global TC current line by PERFORMing scrolling logic, I think [famous last words] 🙂

As far as I can speculate from what I see in the system, when SAP folks themselves went about implementing requirement to expose part of the Budget Billing Plan editing functionality to external world (initially another "express change" Transaction, then CRM system...), they looked at it all and...

1. narrowed down the bare minimum of functionality that absolutely needed to be exposed,
2. programmed another Function Group around the "Yuge, complex type" representing among other state of "object" processed, which reuses via external PERFORMs what validations/state modifications were deemed directly reusable, and...
3. copied the bits that needed tweaking...

There never was and now I doubt there will ever be a BAPI or something resembling it for this... There is now even an SAP Multichannel Foundation for Utilities and Public Sector, no less, with ODATA Entity BudgetBillingPlan, but, alas - still with no POST (Create), DELETE, and with very limited PUT (Change), as of S/4HANA 1909, dear Yevgen Trukhin 🙂 - reflecting faithfully, I suspect, the technical decisions made at least some 15 or more years ago.

And I'm plotting a mission to *err* make the world and our aging system a bit better place! 🙂 and wish I knew what folks who wrote EA61EX FG knew or suspected...

[Private_Member_7726]

Ups, just noticed more, but still not entirely insurmountable, challenges... 🙂

[Private_Member_7726]

I guess I have to take back the comment about there being nothing resembling BAPI, and it's unrelated to the ABAP question, but this IMO demonstrates beautifully the pitfalls of not being able/comfortable/permitted/insert another reason - to refactor "original code". There are now at least 3 Function Groups programmed around the "Yuge, complex type" representing, among other, "object" being processed. Swaths of "business logic" from the original code have been copied with minimal changes, rather than extracted for reuse or adjusted "in place":

And there is still no "generic", reusable API that could easily be exposed, and the problems to solve, should the need arise to do so, or to some day achieve parity in terms of functionality and capabilities among all the "apps" changing the same "business object", IMO have been compounded... 😞

[Private_Member_7726]

We decided against "trying be adventurous" and will wrap only the functionality for which SAP has made at least a function module 🙂