MetaData and MetaProcess: A Non-Trivial Extension of the Notion “M:1”
There’s an excellent SAP ECC BAdI (which shall remain nameless) that has a curious recursive property associated with its “set_data” method: if you call this method, then the SAP engine will re-invoke the BAdI because one implication of calling the “set_data” method is, quite rightly, that something has changed.
So, if you have a situation in which you want to call this BAdI and just set_data once, you’ve got to set a first-time/not-first-time switch in memory (fortunately local session memory in this case), so that you don’t send the system into an inifinite loop.
And if you are invoking this BAdI in several situations where you want to set_data just once, you must set the same switch for each situation.
Hmm … is this not an M:1 situation in the realm of metaprocess instead of metadata?
And if so, why shouldn’t someone else besides Ellison and Codd get rich and famous off a piece of common sense masquerading as “logic”?
How about it, SAP? How about a BAdI engine that would let the user tell the engine what’s calling it and a swtich to tell the engine that the caller is calling for the first time or not the first time?
Surely explication of this construct would be worth a whole season of papers at IEEE conferences, and a whole new school of PERM (process entity:relationship modelling.)
Adding process specific parameters like "channel", "mode" or "origin" to a interfaces violates the principle of separation of business processes and business objects and often leads to complicated IF-conditions ("mine fields") which decide about the process flow at a very low level: IF iv_channel = 'direct' AND ( iv_origin = 'batch' or iv_mode = batch_repeated" ) AND ... So I don't recommend it.
In fact you are asking a very interesting question: What is a BAdI implemetation allowed to do so that the application still works? Some of those conditions are clear:
* Do not do commit work
* Don't refresh BDT memory
...
But with in connection with business processes this question sometimes is far from being trivial.
Best Regards
Tobias
That is indeed an interesting question, TT. Particularly in the context of the "new" enhancement framework where virtually every BAdI has "extension" capability.
Cheers,
Thorsten
Cheers
Tobias
That is indeed a fun idea. The IEEE papers are probably already in existence and at least three independent dissertations have been written about it at SAP. 😉 But let's just fantasize a bit about it.
You could develop a notation for the "invocation cardinalities" between software modularization units such as BAdIs, function modules, instance methods, etc. A hint of this exists already when webservices are marked as "idempotent" in the interface definition in an Enterprise Service Repository. 🙂
But to make the description of the relationship more meaningful, it would have to be a statement about both sides, i.e. the caller and the called. So you would need to define the identity of a caller. Suggestion: a caller is an instance of a software modularization unit in the context of a particular process instance. Or not? And how is process instance defined?
IEEE, take over!
Cheers,
Thorsten
P.S.: To be completely honest with you, David, I don't think Larry Ellison invented ERM diagrams, although he might well think so - perhaps the moon has told him so! 😉
Anyway - yes - the problem is how to define "process instance" - exactly. In this regard I have always that the Web AS needs a little rethinking because it does not respect the time-honored notion of "thread" in multi-AS environments - your "thread" changes when your server changes.
Finally, please note that I never said Ellison invented E:R - I said he got rich off it. But you're partially correct in the sense that he really gor rich by realizing that he could package all the relational mumbo-jumbo in a way that made people think it was something more than common-sense. And technically, E:R is not part of this mumbo-jumbo.
Another idea - maybe the transaction (identified through the transaction id) is a goood candidate for "caller" or "invoker" identity? On the AS ABAP, it should stay the same consistently throughout an LUW.
Best regards,
Thorsten
P.S.: Of course I know you said no such thing about Larry Ellison; I just enjoy the occasional exaggeration, and because in a way L.E. is an exaggeration himself, his image is particularly enjoyable to play with.
I have at least once had to examine call-stack memory segments to see what's in memory and therefore figure out from that what the functional called actually is ... e.g if eban is in memory , the caller is doing a PR, if ekpo is in memory, the caller is doing a PO, etc.
Hmmm - I didn't think this would turn out to be such a deep question, but I guess it actually is.
PS - Ellison - please don't get me started ... interestingly, his success is indirectly due in part to you Europeans fighting Big Blue so hard over SNA vs ISO ... someday the true story will be told
Of course I didn't mean SY-TCODE. Surely you know me better than that! 🙂 No, I mean the transaction id as in a unique identifier for what happens between one particular commit work (or implicit start of the transaction at the beginning of the internal session) and the next. That means a unique key for a single LUW. Several things in the system are assigned to the transaction via unique transaction ids: function module calls queued to be executed IN UPDATE TASK, other transaction types of RFC calls, even PERFORM ON COMMIT calls if I remember correctly. It's been a while since I last debugged the part of the ABAP system where those ids are created and managed, so my memory is a bit vague, but the unique transaction id is there, there is a way to get hold of it, and you can use it for example to selectively roll back functions called IN UPDATE TASK or remote tRFC calls without rolling back the entire transaction. 🙂 It's a nice hack!
(By the way, in Java, the transaction is represented by a unique transaction object, so the concept is similar.)
Best regards,
Thorsten
I know "thread id" and I know the function module to get it - it sounds an awful lot like what you're calling "transaction id".
If not the same, then maybe Rich or Thomas can clarify. I know Rich knows "thread id" because he clued me into the construct as trustworthy so long as you're within the same LUW.
Unspeakable ABAP Mysteries - Part 1
Who will continue this series?
LOVE the Old Germanic script !!! Only way it could have been any better was if it was in runes - but then - who could read it ?
I hesitate to ask - if you are Faust, then to whom in Walldorf did you sell your soul in order to learn the "mysteries", and at what unspeakable price?
I checked the SAP Education catalog, and at least in the US, there is no course whose price is "one soul - collectible upon completion of Exercise 13" ...
I beg to remain, Sir, as Your most obdt. servant,
Thorsten
Thorsten
I'm aware of the VBKEY, which is used to uniquely identify SAP LUWs with regard to UPDATE TASK. You can find out the current LUW key with method cl_system_transaction_state=>get_sap_luw_key( ). For tRFC, there is function module ID_OF_BACKGROUNDTASK which will give you the TID (transaction id) of the current background task. Both keys can be used to do very evil things with the corresponding tables VB* and ARFCS*. I shouldn't be writing this. 😉 On the other hand, the online documentation of CALL FUNCTION ... IN BACKGROUND TASK is very open about TIDs and how you can use them in distributed scenarios.
Best regards,
Thorsten
Thanks,
Thorsten
As soon as I saw it, I remembered it.
But remember, session does not hold across LUW in a multi-WAS environment.
For example, if you call the function in a dialog task MIGO BAdI and then later in a MIGO update BAdI, the function will not return the same value because if the dispatcher sends the update LUW to a different WAS, then the session id on that WAS will be different.
This is why it's not as satisfactory as a true "thread id" - meaning which connectee to SAP am I doing the work on behalf of ?
Salute,
Thorsten