Add-On: Exclude Module dynamically at import-time? Or check module requirements via ABAP at runtime?

[former_member704630]

We have a function module (call it Function Module A) that we are packaging with the AddOn Assembly Kit, so that it can be imported into a System via the SAINT Transaction.

One of our function modules includes several variables of TYPEs from the namespace /gsd/, like such:

  DATA: y_event_ll      TYPE /gsd/oc_event_interface_data,
    y_events_lt     TYPE TABLE OF /gsd/oc_event_interface_data,
        y_ndoc_lt       TYPE TABLE OF ndoc,
        y_key_lf        TYPE rn2doc_key,
        y_xml_lf        TYPE string,

Not all of our customers have access to this namespace. Of course, we could simply build two separate add-ons:

• One for customers who have access to the /gsd/ namespace. This add-on would include Function Module A.
• One for our customers who do not have access to the /gsd/ namespace. This add-on would be the same as the first add-on; except for the fact that we would exclude Function Module A from this package.

But, we are wondering whether there is any solution that would enable us to build only one package. We envision this in one of two potentially possible ways:

• Runtime solution: Within Function Module A, we could, at runtime, dynamically check if the system the module is running on has access to namespace /gsd/. If this check returns positive, we execute this function module as usual. If this check returns negative, we skip this function module. This would presumably require some kind of additional ABAP-code in Function Module A.
• "Load/import-time solution": Is there any way for us to build our package with the AddOn Assyembly Kit in such a way, that, when the customer is importing our Add-on via SAINT, Function Module A is only imported into the system if namespace/component /gsd/ is avialable on the system? In other words, if namespace/component /gsd/ is not avilable in the system, the SAINT import would simply skip Function Module A?

Are either of these solutions feasible - and if so, how? Alternatively, are there any other sensible solutions such that we can build only AddOn for the two possible target system landscapes (one landscape that has /gsd/, and one that doesn't)?

[Jelena]

Hi Christopher! Not sure if you're still awaiting an answer (it's been a while) but to me it seems you'd be better off creating your own types within the add-on package / namespace.

For a long time, we've heard recommendations to make use of existing data types and avoid creating new ones. Not sure anyone could explain with confidence why but it's something that ABAPers were told.

However, more recently ("recently" in SAP terms can be a decade 🙂 ), the word spread out that this is actually not always a good idea. For example, it makes sense when, say, I build a report that shows material number. I know it's MATNR and even if SAP changes it, I would want my program to go along. But in other cases, we should not be using the types that we cannot control.

Many customers actually ran into this issue during ECC to S/4 migrations. Well-meaning ABAPers reused types from some obscure modules but SAP changed them (some were removed altogether from S/4) and now all that code needs to be updated.

An add-on should be self-contained by definition. If you use your own definition that is part of your package then if a customer decides to remove your add-on, they can easily remove the package and everything will be gone with it. Since your add-on can be used with or without GSD part, I'm guessing it's not mandatory to use its definition either.