cancel
Showing results for 
Search instead for 
Did you mean: 

When is customization dangerous even if the BADI's/exits are all there ????

former_member181923
Active Participant
0 Kudos

In this blog post here:

/people/david.halitsky/blog/2007/03/08/the-astrobiology-of-enterprise-soa-how-planet-abap-can-seed-life-on-planet-bpx

I gave a schematic outline of the badi's and exits required to customize SAP QM in a particular way.

Up until recently, it was thought that we only had to use these badi's and exits

to update QALS records in order to link an inspection lot to an inspection plan that is not the one that standard SAP logic picks.

But it turns out that we not only have to update QALS in this way, but also delete SAP-added records from AFFL, AFVC, AFVU, and AFVV and re-add our own corresponding to the operations in the non-standard plan we're selecting for the inspection lot.

OK - so we know exactly how to do these deletes and re-adds, because the way SAP does the original inserts into AFFL/AFVC/AFVU/AVFF (during a MIGO goods receipt post) is perfectly clear - the sequence of FMs and forms is:

FM's:

qeev_tables_generate

qpap_plan_read

qpap_post_qapo

co_bt_order_post_qm

co_vb_order_post

FORMs performed from co_vb_order_post:

affl post

afvg_post (takes care of afvc, afvv, afvu)

But even though we know what we're doing, and even though we can do everythign we need to do with an SAP-delivered BAdI or exit, maybe what we're doing is still too dangerous because we're relying on SAP keeping a number of different files interrelated in exactly the way they are now:

QALS

MAPL

PLKO

PLFL

PLAS

PLPO

AFVC

AFVV

AFVU

AFFL

What do you think ?

Thanks in advance for whatever time you can afford to spend considering this matter ...

djh

Accepted Solutions (0)

Answers (3)

Answers (3)

former_member181923
Active Participant
0 Kudos

Christopher/Stephen -

The customer has wisely decided to get a "second opinion" from another QM specialist as to whether the process described above is "safe" or not.

One possibility is that this QM specialist will come up with a way of changing the standard SAP choice of inspection plan using some SAP-delivered transaction.

If there is such a way, then inside the MB_MIGO_BAD "create in update" method, this transaction could be called "skip first screen" from a function module called in a background task that kicks off upon the usual MIGO commit.

This would, of course, remove all direct updates except those which add the four new customer fields to the MSEG record that MIGO creates during a goods receipt posting.

Thanks again for an interesting discussion.

djh

Former Member
0 Kudos

David,

I briefly looked at the user exits and BADIs you were referring to. I couldn't really determine which one you were trying to use to do your table deletes/updates.

Are the tables you want to update part of the user exit/badi parameters? That is really my guideline for rule number one. If the data is not directly passed into the FM/Method call, do not update it.

In very rare occasions, once or twice, I have really been pushed to update data outside of the parameters passed in. We look at this very carefully. And in most cases it was updating an additional field that was not available, not changing and deleting table entries. But then my view is quite different. I am part of a customer support organization and I have to support the code that goes into our system.

Also once or twice we have seen data inconsistencies, not necessarily from BADIs/User Exits. If a customer introduces data incosistencies into the database, SAP does not like to support the clean up very well.

And sometimes those data incosistencies are quite difficult to track down and you often end up troubleshooting other things. A prime example of this is the use of the user exits in SAPMV45A. These are old form routine user exits, and you can do just about anything you want in these subroutines. A lot of the data is global. We went through a major re-write of these user exits a couple of years ago because we weren't following the SAP Standard recomendations. As a result, we cleaned up some errors in our LIS. We had built a custom program to manually clean up some errors in LIS as a result of our SAPMV45A exits. We could never determine what caused the problem.

Anyway, just a couple of additional thoughts.

Chris

Former Member
0 Kudos

David,

I try to stick to the following two rules for changing data when using BADIs/Exits:

1. Only change the data that SAP is intending to change based on the Function module or BADI method parameters

2. Update customer owned tables that are used for other custom functionality

These are just guidelines and can be deviated from of course. But it tends to get you in the least amount of trouble.

Regards,

Chris H.

former_member181923
Active Participant
0 Kudos

Hi Chris -

Thanks for taking the time to reply.

Your rule #1 is why I find the present case so intriguing from a do/don't perspective.

In goods receipt posting with MIGO, SAP-standard code DOES insert a row into QALS and DOES insert a row or rows into AFFL/AFVC/AFVV/AFVU.

Furthermore, the MIGO exits/BAdI's are located so that one CAN update the QALS record that SAP inserts and delete/re-add rows in AFFL, AFVC, AFVV, and AFVU.

All without a user commit statement - the implicit/explicit commit(s) in the SAP LUW(s) will take care of matters satisfactorily.

So on the one hand, one could argue that this case follows your rule #1 because we're not touching anything SAP doesn't touch in exactly the same place as SAP touches it.

But on the other hand, one could argue that this case doesn't follow your rule #1 because it's pretty clear that SAP didn't intend its MIGO exits/BAdI's to be used to carry out a refinement to the way inspection plans are associated with newly created inspection lots.

Of course, it's the customer who decides the "danger" level in the final analysis.

And when I'm being paid as a developer, I will develop anything the customer wants so long as it doesn't require me to use an access key.

But if I were being paid as a designer, I would probably tell the customer to pay SAP for an OSS note in the above case, rather than use the BAdI's/exits in a "creative" way and risk the law of unintended consequences.

Thanks again for taking the time to reply.

Regards

djh

stephenjohannes
Active Contributor
0 Kudos

David,

Without looking at the exits specifically, there were always a couple of general rules that I followed when using a BADI

1. Never call/issue a commit work during the BADI processing unless the BADI calls for it. This means anything from the explicit commit work statement to any function module that contains commit work.

2. Don't update any SAP delivered table directly(you already know this one). Your Z-code should never contain any update operations that go against an SAP delivered table.

3. Do worry about recursive calls where some module you have called, calls your BADI again. This is quite possible in the CRM BADI programming depending on what you are doing.

So as a long as you don't violate those major three you should be fine. As stated previously on this thread when you upgrade, your headache may occur.

Take care,

Stephen

former_member181923
Active Participant
0 Kudos

Hi Stephen -

I appreciate the responses from you and Chris very much, because my current customer is right now grappling with the question of whether what we "need" to do is actually too much dangerous over-customization. So this is not a discussion in the usual "theoretical vacuum".

I want to explain why I think the "direct update" rule here MAY not apply in this particular case.

But before I do, I want to make very clear that I was the one who brought this situation to management attention when it turned out that NINE core SAP tables were involved, not just ONE. So whereas I felt more or less comfortable with one update to one table to repoint an inspection lot to a different inspection plan than the one which SAP selects, I didn't feel at all comfortable with direct updates to eight other core tables, particular when these involve what amount to "key field updates" - effectively, "deletes/re-adds".

That being said, the details of this particular case involve the fact that when we go for the eight core SAP tables, we are not doing anything other than doing exactly what SAP does, but with different "ALLOWABLE" choices. There are SAP delivered transactions which allow a customer to choose the inspection plan that will be associated with a given inspection lot. These transactions record the customer's choice in two different ways: 1) first - in the relationships among the rows of PLKO, PLAS, PLFL, PLPO; 2) second - in the relationships among the rows of AFFL, AFVC, AFVV, and AFVU. So what we're doing in the exits/BAdI's is:

1) undoing the choice of inspection plan that SAP has made and recorded in these tables;

2) recording our "custom" choice of inspection plan in these tables.

For this reason, it is difficult to BLINDLY apply the "don't do direct updates" and "don't do something SAP doesn't anticipate you doing" rules. Because on the one hand, it is true that SAP does not specifcally say in the BAdI documentation or exit parameters: "use this exit to change choice of inspection plan" or "use this BAdI to change choice of inspection plan". But on the other hand, we are not using the exits/BAdI's to do anything different than SAP already does when MIGO GR posting triggers inspection lot creation and inspection plan assignment.

With respect to the "watch-out for problems during upgrade" rule of thumb, it is also difficult to apply this rule blindly because it turns out that in our case, all the columns in the relevant tables are KEY columns. And for that reason, it is hard to imagine SAP changing its fundamental "E-R diagram" for QM during the course of any future upgrade. And if this possibility is, in fact, remote (i.e. if SAP cannot really change the "E-R" key columns of QM tables without rewriting QM from scratch), then the "upgrade problem" issue really doesn't arise.

Anyway, I want to close this post by saying that the functional analysts who proposed the customization in the first-place do NOT think that direct updates of nine core SAP tables is overly dangerous, and this is why management has to make a difficult decision between what the functional consultants are saying and what the in-house development lead is saying.

As a consulting developer, my job (fortunately!) is to collect the relevant facts and present a clear picture to the development lead, so that he or she can in turn present a clear picture to management.

It will be interesting to see the eventual outcome of this situation, and I will of course report this outcome back to this thread.

And again, thanks very much for taking the time to respond.

djh

former_member181923
Active Participant
0 Kudos

PS - I just wanted to add that I overstated the case slightly in the above post.

The customization does not have to hit the core tables PLKO/PLAS/PLFL/PLPO.

It has to use the info in these tables (plus info in the MAPL table) to reset one row in QALS and potentially multiple rows in AFFL/AFVC/AFVV/AFVU.

But anyone who thinks that hitting one SAP table is one hit too many will probably not see a whole lot of difference between hitting five SAP tables and hitting nine ...

stephenjohannes
Active Contributor
0 Kudos

David,

I kinda thought you were doing "direct-updates", that's why I left my answers more "high-level". If I put on my old consulting hat, there are some very valid risks if you choose to go down this path:

1. In upgrade SAP can "reorganize" how things are stored, etc. We know this rarely happens, but it can happen. Once again, you may need to adjust your code during an upgrade, but not a big deal.

2. Technically direct updates to SAP tables via customer code are a violation of the SAP license agreement. SAP can refuse to support any issues that are caused as a result of those actions. In other words, you could cut off support for other "bugs" due to the fact that you violated that rule. In this case you might want to ask the functional consultants if they ever read the SAP license agreement and understand fully that those changes will not be supported by SAP.

Worst case scenario the client has to pay for SAP development support to come in and "cleanup" the system.

Now if everyone understands the implications of what this means, and are comfortable with the above issues, then you should proceed forward. I personally would not want to explain to management why SAP will not support us if we have issues going forward in that particular area.

Good luck,

Stephen