Skip to Content

I want my money back for BC425U ! Or do I?

<p>When I took the Enhancements and Mods course back in 2004, they never told me a little secret that all the pro’s seem to know.</p><p>The little secret consists of two declarations:</p><p>DATA wa_structure(n) TYPE c VALUE ‘(program_name)structure_name’.</p><p>FIELD-SYMBOL <fs_stru> TYPE structure_name.</p><p>and one statement:</p><p>ASSIGN (wa_structure) TO <fs_stru>,</p><p>That’s all there is to getting a hold of any piece of memory in any program in which you’re executing an exit or a BAdI (assuming of course that you can figure out the name of the relvant progam, which isn’t always as easy as it sounds.)</p><p>And of course, the ability to do this permits you to extend the “reach” of virtually any exit or BAdI that provides a convenient place for you to put some custom code.</p><p>For example, ‘(SAPLMEPO)ekko” gives you ekko (PO) data in the middle of an FM derivation BAdI, even though SAP isn’t kind enough to pass the ekko structure to the BAdI. </p><p>So, should I demand my money back?</p><p>Well, one part of me says absolutely, because by not teaching me that trick, SAP sent me out to do battle with dragons using only a slingshot.  And I’m not as good at that as my Biblical namesake.</p><p>And the other part says, well – maybe it’s really a trick that folks shouldn’t learn until they’ve been “on the job” a while and are doing work that’s sufficiently advanced enough to warrant some senior person clueing them in.  </p><p>Because if you know the trick too early, you lose incentive to find out how to do things the hard way, and that can be extremely instructive.</p><p> </p><p> </p>

You must be Logged on to comment or reply to a post.
  • Hi David,
    i´ve gone through all that as you did although i didn´t take the BC course.
    I´ve experienced the same feeling.
    Thanks for putting it into words.

    Best regards.

    • Hi David,

      User-exits and BADIs can be called form functions / BAPIs etc .You may realize later that particular structure does not hold any value so all you get is a dump.

      You should not do this unless you are sure what you are doing. There are better ways to achieve this.

      I would say demand your money back if they did teach this in official training classes.


        • "If assigned" will only save you from the dump.

          But your code will not work for the cases when structures are not populated because it's being called from an API and not a transaction screen.

          • As you point out, the method should only be used in cases where you are using the presence or absence of data in the strucutre as an indicator of what's calling the BAdI.

            In this case, the BAdI has to exit if it's an on-line situation and the t-code is not ME51n or ME52n.  (This is because the FM Derive BAdI is a very general BAdI that's called all over the place.)

            But when we're doing a PO via BAPI, we have no sy-tcode to check.  So we check to see if there's a bstyp and bsart actually in ekko and if there is, then we know it's safe for the BAdI codee to execute (because we're doing a PR or PO.)

            To restate the point, in this case the method is "safe" because it's precisely the presence of a "filled" or "empty" structure that correctly tells us what to do.

          • I am completely with you - some BAdIs get called from all around that people have to do crazy things to make it work.

            But if a large section of the community feels the pain - couldn't a mentor take this up with the labs organization and get the original design of the application fixed?

            From personal experience, I was engaged on some CRM development work that SAP did for a new module and usually the product managers and architects were more than happy to fix the problems if they are pointed out with good use cases. Of course, there were occassional "can't do - it is a framework thing" type of excuses, but there were ways to work around that.


  • They probably didn't teach it because it is unsupported syntax reserved for internal usage only. It is listed as a note in Alternative 4 of the ASSIGN Keyword documentation. 

    This construct exists for internal usage because it was needed by the old debugger.  The old debugger ran in the same session as the program being debugged and therefore needed a way to read out of context memory variables. 

    This syntax was never intended to allow you to read beyond the intended interface of a BADI or other exit construct. 

    This syntax is no longer required in the new debugger do to the 2 session structure and remote attachment capabilities.  You can imagine that someday SAP might do away with the old debugger and in the process disable this syntax. Since it is marked as internal use only, SAP can remove it if we feel like it.

      • >Is it a threat or a promise?
        Neither. It is just a statement of the facts. This language construct is documented as internal only. Internal only means SAP doesn't support its use by customers or partners and we don't take responsibility if you disregard that warning.
  • Hi David.  I am guilty of using that trick in the past as well.  Let me tell you, it has saved me numerious times and fixed some very big problems at my former company.  Just one more word of advice.  In my experiences, I have only ever read from these memory spaces, and I would suggest never to update the values like this.  Doing so carelessly, could really screw up your system. 

    Rich Heilman

    • Yes - I agree completely - and anyone who tries to write into SAP-controlled memory areas deserves all the grief you're going to buy.

      It's funny you made the point, though, because I was wondering last night whether SAP "fences" its own memory by making it read-only even though anyone can get to it. 

      From what you're saying, I guess not.

      Best as always

  • The dynamic assign to memory areas outside the scope intended by SAP is a bad habbit - so I hope this is why the pro's has kept this secret.

    Your program logic will fail/lead to missing results if:
    - the variable is rename
    - the variable is moved or deleted
    - the program execution flow will be changed
    - the scope of the variable is changed (local/global)

    You will get no help from the syntax checker when you apply oss notes or upgrades the system..

    The internal development policy in a company will change if you allow dynamic assigns - first you allow dynamic assigns, and the next step will be an discussion about updates using the same method.. which is really bad programming.

    If you need to access data outside a userexit/BADI consider an enhancement (explicit or implicit) and export the relevant data to memory - or build set/get functionmodules in a functiongroup with global data and use this to pass data to your userexit... If you use enhancements you will have the syntax check to help you verify ossnotes and uppgrades and have a fair chance to correct your coding.


    • As some of the regulars in the ABAP Forum can verify, I have coded more "exports/imports" to various pieces of SAP memory than I care to remember at this point.  In fact, I was the guy that ruffled SAP's feathers by pointing out that "SHARED BUFFER" is a little bit of an exaggeration and that the construct should be changed to "SHARED BUFFER ON SOME SERVER", just to warn the unwary.  (Well, I think aRs or someone else actually suggested the change in wording, only I think it was a little snarkier, like "SOMEWHAT SHARED BUFFER".  Anyway, it's up to each installation to decide how they want to handle this issue, and I agree that the "right" way to do it is to use standard memory techniques.  In this regard, you may not be aware that at the headquarters internal unit of a major US SAP premium partner, the ABAP development group prides itself on running its own flavor of SAP in which many pieces of pristine SAP code have been altered via access keys.  So even though the "assign" trick seems like a really bad sin, it's only "venial" compared to some of the "mortal" sins that are being committed by folks who should know better.