Why does SAP invite customers to violate rules of the game re mods?

[Former Member]

In a recent blog post, I noted that there is an odd pair of customer exits in XQQM (called from IQS0) that receives the global structure for a view (VIQMEL) and passes it back to the SAP-owned code behind the PM transaction IW2n.

As noted in the blog post, VIQMEL is a dictionary view that sucks in the entire QMEL table, and since we we have put a custom append structure at the end of QMEL, this append structure is part of the VIQMEL view.

But here's the odd thing. When I do a save in IW22 after the customer exit has been called, and data for the append structure has been placed in VIQMEL ...

<b>... the normal SAP code updates QMEL with these data.</b> !!!!!!

But doesn't that mean that if I changed SAP-built data in VIQMEL, SAP would take these changes too ?????

And if so:

<b>isn't SAP inviting inexperienced customer programmers to violate the rules, instead of using the BAdI interface/method IF_EX_NOTIF_EVENT_SAVE/CHANGE_DATA_AT_SAVE</b> ???

Additionally, if I'm correct in the above analysis, I'd be curious to know how many other functional modules has SAP "opened-up" to lazy and ignorant customizations ????

Please respond if you yourself have encountered any.

Thanks much.

djh

[Former Member]

Rules re Mods? Judging by questions asked in forums here, any such rules are not widely known, and even less widely followed.

I have seen numerous posts asking for instructions on how to do mods that I would simply tell the customer "No - Not Possible". (Of course, you then have to explain why and present options for obtaining the business result they want without the risks - but I like a good discussion).

The scary thing is, the number of replies that tell obvious newbies things like "just insert directly into the table" or "Get the access key and change it" or "Just copy the function group and all includes and FM's and modify to do what you want".

A lot comes back to two basic items - "You get what you pay for" and "Buyer Beware". If companies want to save a few dollars by employing the cheapest / inexperienced resources that they can find, and this results in someone using an exit / mod / transaction / etc. in a way that potentially damages their data then that is something they will have to live with.

Having a few exits where it is slightly easier to get things wrong is not really adding to the issue. With the new enhancement framework you could simply go straight to the implicit points in the forms of the code behind IW22 and replace the standard code completely - why not have it update the Travel tables instead?.

The bad effect of this is if you are the person employed at a later date to fix the problems. I am sure everyone with some years of experience has stories like "I wrote a little ad-hoc program to reload and fix the data in ..." - you just have to look at the number of such programs released via OSS notes to see that SAP programmers are no better / worse that the rest of us in this regard.

I think that the main issue regarding "rules of the game" regarding mods is one of

gaining the trust / respect of the employer so that you can answer "No" and they will accept it.

So if the lazy / ignorant / inexperienced get it wrong - there is always last weeks backup (or did I mean last month? year?). Early retirement is looking good.

Andrew

[Former Member]

Hi Andrew and Dave,

Can't help it - I have to throw in my 2 cents. I was told a few years ago that a moments thought avoids many lines of code. How true this is.

The problem is caused in part by the motivation to produce a solution in the shortest possible time, rather than the best solution for all time. Often cowboy solutions seem good because they can be applied quickly. But when the time comes to maintain, modify or upgrade the saving in the first instance is repaid many-fold.

But the main cause is having to make up for a lack of ability and knowledge on the part of our functional colleagues. Some of the worst modifcations I have seen have been cunning attempts to engineer functionality which SAP already has, and with more knowledgable design would not be required. I once saw an extensive workflow system built without any BOR references, event modelling or org and agent model. All operations were conducted on the workflow instances by custom module pool applications and periodic background reports. The reason for this setup was the site being unaware of the basics of the product. At least the replacement looked, ran, and was easier to maintain, used less system resources, and was easy to upgrade and incorporate into UWL and other standard portal features.

But I bet it looked like chocolate when it was first unveiled.

Regards

Gareth

[former_member181923]

Hi Gareth -

That is, of course, way more than just your "2 cents". Your posts usually are.

Anyway, when you write:

<i>But the main cause is having to make up for a lack of ability and knowledge on

the part of our functional colleagues</i>

you wouldn't be referring to present members iof the BPX community, or to trainees preparing to be future members of this community ?

(Sorry, Marilyn - it was a cheap shot but I couldn't resist - the devil made me do it.)

You know, Gareth, I was kinda hoping that with the departure of Shai and with the published percentage of the client base still at 4.7, SAP would start paying more attention to the kinds of issues we're talking about in this thread.

If only, as I've said before, to train folks in the right way to think about BPX even when they're still in the older CMOD/BAdI contet that SAP hopes to supplant with an SOA-reliant/SOA-compliant back-end.

But somehow I don't think it's gonna happen, for the following reason.

CIO's are getting younger and younger (compared to me), and they've spent their formative years thinking "bling's the thing" - the blingier the software, the better.

And the one thing you don't want to have to deal with when you're buying bling is real IT issues - the kind that turn "low-risk/high-margin" deals into "high-risk/low-margin" deals.

Best regards as always,

djh

[former_member181923]

Andrew -

Please forgive me for not previously noticing your response in this thread.

Your points are equally as telling as Gareth.

Shame on all of us for our acquiescence in what goes on day-in day-out, but never gets talked about at Tech Ed.

Regards

djh

[marilyn_pratt]

Yep. It was a "cheap shot" David and it sure got my BPX goad.

Actually, tying the fault to functional folks can be thought of as the epitome of geek hubris ...the cliche example of geek gap behavior. As if <i>only</i> functional folks were the perpetrators and originators of poor coding and ill-thought out modifications, with no thought of process strategy.

And I must set you to rights, David about projected discussion topics and opportunities for honest discourse around these and other burning issues at TechEd. TechEd is <i>exactly</i> the place (clubhouse, community day especially) for such conversations. In fact these are actually being planned (at least in Las Vegas) with moderators and panels and I'm sure will happen in Munich and Bangalore as well. Community Day in Bangalore and clubhouse activities there last year had panels and informal meetups that spoke about the challenges of evolving out of "code monkeydom". I don't think our community is shy about honest BPX critique either....or at least not in the conversations I've been privy to.

And such an event is also the <i>exact</i> venue to engage with real customers and real community members of SDN, BPX and ASUG in LV around how experience and reality maps to product and functionality. I think you'd be surprised to hear what some companies are already doing in their business transformation activities. I would hardly want to marginalize their engineering successes with creating "process centric enterprises where IT supports process leadership teams in initiatives" and where "customer requirements are front and center in driving the selection of process improvements" (direct customer quote).

[former_member181923]

Marilyn -

If anyone can make it happen, I'm sure it's you. Seriously.

I wish you the best of luck. Seriously.

At the same time, I have yet to see any recognition by SAP here at SDN or elsewhere that BPX is a construct that can be taught to and applied by customers who are still in the pre-SOA CMOD/BAdI back-end context - that what's worthwhile about BPX is technology independent.

This leads me to suspect that it is perhaps the BPX evangelists themselves who have too closely tied BPX to a particular technology - namely the PI/VC-related technology that SAP is trying to talk its customers into buying into.

Why not some classes/panels at TechEd on how customers can apply BPX using exits and BAdI's, as well as PI/NWDS/VC, et al?

Or would this destroy the mystique of BPX as a sales-driver for PI, NWDS, VC, etc.?

Sorry to be cynical ... I just don't see anything about any BPX construct that would prevent it from being applicable in a CMOD/BAdI contet.

Best regards as always

djh

[Former Member]

Hi Marilyn

Well no functional people aren't responsible for <i>all</i> poor code and ill-thought out modifications. But the point is that both the programmer and the funky have to be aware of the actual product as it evolves and keep across all the advances in their toolset. The longer I keep doing this the more I realise what the base system can do, and this should over time minimise all (basic) mods at the net function level. Which means we use BaDIs and exits for specific purposes pertaining to the instance of the business process for a specific site's needs.

Although as programmers we enjoy having fun with our functional friends (ie what do you call someone who hangs out with IT pros? A funky), in reality the outcomes shame and praise the TEAM. A crap solution is crap regardless of cause and fault. It has gone through several hands before even hitting UAT.

<i>customer requirements are front and center in driving the selection of process improvements</i> is absolutely correct, but the actual design and build of the improvements is the responsibility of the functional and developer and THEY should always be trying to use the supplied functionality of the systems and technology before rushing to "enhancement points".

Regards

Gareth

[marilyn_pratt]

If you have the patience, go to the BPX homepage. There is a recording of an ASUG webinar (attended by over 400 customers). Skip forward to the segment presented by Deb Boykin. Her presentation piece is called: <a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/b00d60a0-8b3b-2a10-e9a2-bf5c2fcb3b00">Engineering the Process Centric Enterprise</a>. If you want authentic, vendor neutral customer generated ideas about where this is all headed...

Why are you so stuck on talking about BADIs for goodness sakes? That's sounds awfully SAP-centric to me and certainly not "BPX as technology independent".

[former_member181923]

Marilyn -

You write:

<i>Why [am I] so stuck on talking about BADIs for goodness sakes? </i>

Easy.

That's where the vast majority of SAP's customers live.

What's always worked for me is to take folks from what they know to what they don't know.

So that means teaching BPX to SAP customers where they live, not where SAP would like them to live.

And if SAP were to do that, perhaps SAP customers would want to find the next place to live faster than they are currently being convinced to do so by all of SAP's BPX pitches..

Regards

djh

[marilyn_pratt]

I agree with <i>almos</i>t everything you've written Gareth ...especially "THEY should always be trying to use the supplied functionality of the systems and technology before rushing to "enhancement points". I guess the idea of the evolving responsibilities of business process professionals is that they will eventually be looking to share some of the responsiblity with the funkies and developers.

As someone working for a software vendor, it is "interesting" for me to observe that business process improvements could very often be changes that have little to nothing to do with modifying, enhancing, extending or otherwise customizing code so if the BPXers are engaged in analysis and design...they might very well NOT want to jump to a software conclusion. In other words not rushing to a technology solution

PS. I like the "funky" term. And a geek hanging out with funky becomes gunky? maybe not ....that sounds like something bad sticks to them and they are worse the wear.

But seriously, what I like best about what you've written is the TEAM concept because having the gunkies, funkies and bpxies working together is probably a better endgame them having them each drive off without any engagement, discussion, discourse, dissent and then suddenly doing an about face and pointing fingers of blame when it all goes wrong....

[marilyn_pratt]

You miss my point. I'm concerned with an undue focus on changing code, be it with BADI, CMOD, WSDL extension to an enterprise service or plain, bad-a**ed modifications. Those done without working together with business analysts, process professionals and business folks to see if the dern code change is necessary in the first place.

[Former Member]

All,

As I have learned with our recent ESS/MSS implementation, it is even more necessary to have developers and functionals working closely together.

Even though the "SOA" architecture is not yet there on the HCM side in 2005, SAP has definitely followed the guidelines of separating out their front end and back end logic. (ESS/MSS is delivered in Java Web-Dynpro).

One of the things that I am hoping to talk about at community day in my BOF session is how it is now more than ever important for the functional types and developers to understand each others world. And also how important it is for both to understand the IMG. Without this understanding and working together, we would have ended up with many more lines of custom code and custom applications in our roll-out.

Perhaps we can also extend this conversation and do it again in the clubhouse later in the week in LV.

Best Regards,

Chris H.

[Former Member]

Chris,

unfortunately, what you describe and which I agree very much with, IMHO is in contradiction to what the marketing machinery of the big vendors tries to sell their customers.

In my understanding they try to tell people that, with their new toys or tools like VC and stuff, the functionals will be enabled to metacode a lot of processes without a need to understand the technological aspects, things, developers are usally concernend with.

Sadly, lots seem to buy this promise, not realizing that, if at all, with this meta approach they will always only be able to project kind of 'trivial processes', deployments which probably will never resemble any major USP for the user/customer but only some mainstream (commodity) stuff.

I am strongly convinced that (of the companies building their processes on IT) mostly those excel, that are able to go beyond the standard tools given, those that really command the underlying technology, those who can gain an advantage over their competitors by being able to combine the innovative powers of their biz and tech people to build solutions 'never built before'.

So, I'd like to see someone call back the marketing visionaries and let free the socially competent moderators, mediators and team builders.

my 2 cents, anton

[former_member181923]

Marilyn -

Yes - I agree we're talking at cross-purposes.

As my current client has amply illustrated over the past 18 months, your "process-centric" and "customer-driven" applications can just as well be written using older tools (BAdI's and exits) as they can be using the "latest and greatest" tools - WDA, WDJ, NWDS, VC, GP/PI.

So I am not emphasizing "changing code" - I'm emphasizing the use of certain technological tools to achieve the same goals as you are trying to achieve with a different set of technological tools.

And I repeat - it is you who's tying BPX and the notion of "process-centric/customer-driven applications" to a particular kind of code.

If SAP would invest a little time and energy thinking about how its older tools can be used to implement BPX just as well as its newer tools, it might do better at getting its pre-NW customer base into the frame of mind where it feels more ready to buy into (and buy) WDA, WDJ, NWDS, VC, GP/PI.

Anyway, I think we've beaten this one to death.

Best regards

djh

[former_member181923]

Anton -

We are in complete, and I mean complete, agreement. Thank you for saying what you said as well and clearly as you said it.

The very fact that we are in complete agreement is something that SAP should consider carefully, because you and I are at such opposite ends of the spectrum technologically.

What I mean by this is that if two "opposites" (such as you and I) <i><b>both</b></i> see the naked emperor, then there is a high probability that the emperor really <i><b>is</b></i> naked.

Regards

djh

Regards

djh

[marilyn_pratt]

Anton wrote: "those who can gain an advantage over their competitors by being able to combine the innovative powers of their biz and tech people to build solutions 'never built before'....So, I'd like to see someone call back the marketing visionaries and let free the socially competent moderators, mediators and team builders."

Sounds like a powerful call to action. Interestingly some of the very market speak you decry claims that a BPX community can be the perfect environment to nurture and train those that bridge and innovate.

Would it surprise you (and David) to know that a community-serving BPX evangelist(from my perspective,) should help discover, identify and advocate those in the second group (competent moderators mediators and team builders) and likes to see them displace the voices of hype. Okay, evolving the "evangelism" and dropping pre-conceived notions about the players is a process. Understanding and listening to the "real" voices, takes time, practice, experience and certainly isn't an error free activity. Vox populi sessions ...real ones ....are something to think about supporting and nurturing. Sharpening the stories around the conflicts and pushing forward less savory opinions might be a necessary step in the process of mediation and team building. We seem to do a fairly admirable job of that in this context (at least providing the platform for the debate and welcoming voices of dissent...although it might not always feel like that, gentlemen). It's also possible that our "communities" (SDN and BPX) are ideally and uniquely postioned to live under one umbrella network where business folks,functional folks and developers not only rub shoulders but learn to listen to each other and perhaps understand that "they need each other to survive". In a conversation with the Geek Gap authors, Minda Zetlin and Bill Pfleging, I gathered that in the scope of their experience, many of the mediating conversations they attended or led took place separately: in board rooms with suits, or in IT departments with geeks, but seldom were there opportunities for them(the authors) to really have productive "shoot out" sessions like we can have here where both sides get to really listen and hear. Am I naive to think that providing the platform for this kind of debate brings us closer to recognizing "competent moderators mediators and team builders"?

And again, don't events like the upcoming community days and clubhouse roundtables provide a stage for such public hearings on "marketing machinery".

My feeling is that groups like ASUG (strongly customer driven) do an admirable job of battling vendorspeak. We, in our community, do well to learn from them. And as I am learning here in these discussions, it is very hard to be a "human face of a company" without being perceived as being part of the marketing machinery. The real evangelists, the real weight of BPX power, needs to be in community hands. That's also the idea behind the BPX Knowledge Table in TechEd and the BOF sessions in community day. Open mike and lots of opportunity to be heard.

[former_member181923]

Marilyn -

You are perceiving my posts in this thread as an attack on BPX itself.

They aren't.

They're an attack on the notion that BPX has to be tied to a particular technology -amely, the current flavor that everyone is trying to sell.

And this to me makes BPX evangelism highly suspect.

All you'd have to do to decrease my skepticism and cynicism (and perhaps that of others here) is to indicate your (and SAP's) agreement with the basic idea that "process-centric" and "customer-driven" applications need not be tied to any particular generation of post 4.6c SAP technology.

But so long as you and SAP continue to seem to claim that "process-centric" and "customer-driven" applications can only be built in VC/NWDS/WDA/WDJ/NW200nx/NWDS instead of in a BAdI/exit context, or can be built using GP instead of WF, then you have to expect a certain degree of skepticism about motivations.

Regards

djh

[former_member181923]

Sorry - that should have read "can <b>only</b> be built using GP instead of WF"

[Former Member]

> All you'd have to do to decrease my skepticism and

> cynicism (and perhaps that of others here) is to

> indicate your (and SAP's) agreement with the basic

> idea that "process-centric" and "customer-driven"

> applications need not be tied to any particular

> generation of post 4.6c SAP technology.

Does the question need answering? Take a look at when some of Michael Hammer's and James P. Womack's books came out and check wahat version most sites were on at the time.

[former_member181923]

Hi NXO -

Thanks for taking the time to weigh-in.

I recall hearing Michael Hammer speak in the 90's - I'm pretty sure it was 1992ish in Nashville at the annual meeting of a database company for which I was working at the time. Anyway, it was when he was already a big shot.

So if I read you right, you're kind of <b>agreeing</b> that a mix of BAdIs, BAPIs, exits, andworkflows can be used to knit pre-NW SAP apps together in exciting ways that are <b>just as "process-centric" and "customer-driven"</b> as the results achieved by using NW200nx/NWDS/VC/GP/WDA/WDJ technology.

Or am I misinterpreting you comment here?

Regards

djh

[Former Member]

What I really mean is that you can build process oriented apps with old technology, it's more about how you use it. Even going back to R/2, the fact that it was integrated was one thing helping to break down the organisational silos, that were often mirrored on the technical level by separate depatmental systems, overnight interfaces, handovers, replication...

Eeeh, they don't know they're born these days.

Equally, you can use a dictionary full of buzzwords and still build something that isn't process oriented because the underlying requirements (what it should do) weren't thought through.

At the risk of sounding a bit woo-woo, it's a way of thinking as much as the tools you use.

[former_member181923]

that's not "woo-woo" at all, NXO.

In fact, it helps to clarify something I've been trying to find a way to say here at SDN all year -

if you get pre-NW folks thinking about how theycan use what they have to create "process-centric" and "customer-driven" IT, the successes they achieve might actually make them more receptive to the newer forms of technology that support "process-centric and "customer-driven" IT.

But of course, that's a long-term sales effort and sales pitch, with much less near term reward than what you can reap by blinging CIO's into thinking they can't hold their heads up among their peers unless they buy everything new that's coming down the pike at them.

Regards

[ChrisSolomon]

Oh come now, David....have you not learned that SAP over it's many years has provided all sorts of wonderful tools and methods for the "inexperienced" to hang themselves, shoot themselves in the foot, bang their heads against the wall, and generally dig their own grave. That's that dark German humor for ya! haha 😃

Seriously though, I think it is more a matter of SAP being so "large" in scale that many of it's pieces are built/developed by separate groups with inconsistent overall direction in how or what they choose to support/build....coupled with the vast changes needed to keep up with urgent patches, hot fixes, etc. In general terms, I think the left hand often had no clue what the right hand is doing....and the poor feet get left out in the cold all together! 😃

[former_member181923]

Chris -

As usual, thanks very much for your pungent, acerbic, and hysterically funny humor. And you're right - is it "gallows humor", as they say.

But I'm curious - since you know what I'm talking about here in general, and see the danger of it, have you ecountered any other major transaction group other than IW2n with the same "loophole"?

If so, do you recall what the transaction group(s) was or were ???

Thanks for whatever time you can afford to spend searching your considerable "institutional memory" for examples of this you yourself may have seen.

Best regards, as always.

djh

[former_member181923]

PS - Chris - I'm very very happy with SAP right now because the function "READ_NOTIFICATION_BUFFER" works exactly as advertised.

Otherwise, I might have expressed a little more cynicism as to why SAP builds loopholes into exits that inexperienced customers can use ...

<b>... something having to do with claiming that "free-support" for the transaction group in question is no longer available !!!!</b>

But as I said, I'm so happy with SAP right now (seriously!) that I'm not going to go there ...

Not now, anyway. I'll wait till I have to send in my next OSS note on an SAP helper "report" program that doesn' start with "REPORT" ...

Regards

djh

[Former Member]

David,

How about SAPMV45A? What better way for an inexperienced developer to hang themselves than subroutines with access to all variables in your sales order processing?

And where else in the system do you have to maintain 2 internal tables (X and Y) and set your Update indicator correctly to ensure your database updates go through the way intended?

At one point in time, we had to run a whole separate program to clean up SIS Infostructures with direct table updates because of some code in these userexits that was done incorrectly.

Cheers,

Chris H.

Message was edited by:

Christopher Hanshew

[former_member181923]

Chris -

Wow - I'm blessed with a pair (brace?) of Chris's this morning!

Thanks very much for taking the time to respond ... that's a CLASSIC!!!!

Best regards as always

djh

[RichHeilman]

Well David, I just want to add that really any user exit allows for a developer to do pretty much anything he wants. Even though certain things are being passed to him via the function module parameters, there is absolutly nothing stopping him from accessing data in the call stack via a field symbol. So if he wanted, he can change any value within the SAP standard code. Possible and I have done so in the past, but not recommended at all.

Regards,

Rich Heilman

[former_member181923]

Hey Rich -

While I always defer to your extensive and superior knowledge, I think you'r e making an overgeneralization that misses the point a little.

The XQSM exists do NOT make the "real" copy of QALS available and you can NOT change the "real" QALS data within it.

Nor in a very old financial BTE that I investigated last year.

Regards

djh

[former_member181923]

Oh - yeah - and I forgot the most important parallel example - the MIGO exits that DON"T pass you the real MSEG structure. In that case,which Rich and Suresh and Narendran all were kind enough to help me with (because of the need to get context id to make the structure unique in shared buffer), the standard MIGO save knows nothing about any custom append to MSEG. So from my point of view, the IW2n QMEL case was very much a surprise and seemed to be a big exception to the "rules".

[Former Member]

Two - (X and Y)? We have Z too. Because, according to the comments, if you loop at internal tables it corrupts the data.

The advantage of this approach over, say, using LOOP INTO or LOOP ASSIGNING is that isntead of there being only two ways the tables can be out of sync, there are now 3!, i.e six.

[former_member181923]

hi nxo -

What a real pleasure to see a substantive comment at the Coffee Corner.

Judging from the recent traffic here, one would think that SAP was in the point-redemption business or something, like AMEX or Discover.

Regards

djh

[Former Member]

This message was moderated.

[Former Member]

If you're going to hijack a thread:

Please make sure the thread is relevant.

Please make sure the thread is in a relevant forum

Rob