Prefix Block
***************
Re-Inventing the wheel - Everyday!
*Disclaimer* - Notes in my blogs are about hypothetical scenarios. They do not directly or indirectly relate to any of my current or prior employers, or their clients.
Why this blog?
I quote you "Humans are unique among all animals because of their ability to learn from others mistakes. What's even more unique is their reluctance to do so!"
What makes me qualified to comment on this subject?
I have been in Production support Environment for about 10 Years, at least 5 of which supporting SAP ECC. One of the project I have been involved with claims to be the largest SAP ECC implementation worldwide.
Target Audience, or Why should you spend time reading this?
This Blog is about how simple design elements can save hundreds of Hours, money and sometimes embarrassment from your Client or Customers in long run for Large scale IT projects' maintenance. Often, IT projects are driven by urgency to deploy quickly, and fail to consider how it will be maintained for years to come.
Sometimes they include exotic design elements that are too difficult to sustain for many users across many locations. (May I quote an extreme imaginary scenario? "Don't build a Unicorn if you don't know how you would you feed it Gold crusted Diamond Pie everyday!"
All developers may find my comments useful. Technical Project leads, Architects, or Production support personals may find these more valuable than others.
Leave me Comments!
Your project situation may differ so my notes may not completely apply to you. However, I like good debates, and I am willing to listen!
If you don't mind, please mention your production support experience if you have in your comments.
I hope you got the idea where I am going with this.
***************
Let me start my 2nd IDOCs Feature request with same notes as the 1st feature request.
SAP has built IDocs functionality which is an amazing tool that makes processing large transactions in parallel or sequence very easy. It has detailed load distribution, tracking, and reprocessing mechanisms.
However, I think SAP somehow missed to build simple generic data analysis tools around IDocs. (How did you? You can convert currency 300 different ways!)
I have had our projects build 5 custom tools for IDocs. They are saving us hundreds of hours (and sometimes things that money cant buy).
2ndof our most used IDocs tool is IDocs Mass Data Corrections.
How does it work?
We borrowed WE09 selection screen since it has most fields needed.
Key Selection criteria are (some standard WE09, some added):
- All the standard WE09 EDIDC search criteria.
- Segment Name
- Segment Number (Each segment has a unique sequential Segment number. Segment number is needed because a segment is often repeated multiple times in IDocs. You should make sure you are not changing incorrect Segment.) Leave this blank if you wish to change all segments.
- Field Name
- Alternative to Field name: Starting character position, and number of characters
- Current Field Value (Type in * if you don't care about actual current value)
- New Field value
Output is ALV grid showing EDIDC info along with Segment number, Field name, current field value, and new field values.
Cells for new field values are pre-populated with replacement value from selection screen but they are editable if someone wants to edit them once more.
Next, users can select individual rows or all at once and hit “Replace/Execute” button which will go thru all selected segments and replace old values with new.
Our implementation can be used to look up one field value and do substitutions only for that one field. Someone could easily extend it for multiple field lookups and multiple replacements. However, this gets complicated right away, and not worth extra trouble for us to develop. We found running this tool multiple times easier than to develop N to N replacements (we chose to go for LSMW instead for N to N scenario).
Key Development criteria:
- Make sure you do S_IDOC_MONI.
- This is a very special limited use utility. Add another custom security auth that no one will have by default already, preferably custom S_TCODE. Also add a Z table with User ID and Valid dates to run this utility so someone cannot accidentally run this utility, and not know what they did.
- Leave an audit Trail like WE02. Whenever IDocs are edited via WE02, SAP creates copies of the originals (ex. 70s for inbound) and changes current status to Edited (69 for inbound). Make sure you implement this too by using standard SAP FMs in WE02.
- Not all statuses can be edited. Ex. 53s, or 70s. Make sure you don't allow this utility to edit them, just like WE02.
- Make sure you can do an LSMW on this. Sometimes, you may have a very large load or varied data which will make this utility too manual to use. Our implementation allows LSMW for N to N replacements.
Why is IDocs Mass Updates needed? How will this help you?
- This should be used only as a last resort under very tight timeline in production. Ideally, the source systems should always update data and resend.
- This tool will be very useful in Dev and QA environments, especially in early phases of development and testing when all pieces are not in place, or not working as expected.
- Dev/QA: XI/PI mapping mistake and no Material numbers in IDocs? No problem! Use IDocs Mass Update to add material numbers and continue testing!
- Dev/QA: You have some old test IDocs lying around but dates are too old in them? No problem! Use IDocs Mass Update to change dates and continue testing!
- Dev/QA: You don't have to go find your middleware guys to find you original Flat file/HTTP etc. and manually edit it, and resend it thru all layers. This could sometimes take hours or days depending how busy or willing they are, or if that particular instance of the system has working middleware hooked up. This tool can be virtually used by anyone with least amount technical knowledge. If they konw WE02, they can use this!
- Prod: Error in ABAP on ECC to partner interface that put some wrong values in outbound IDocs, and now you don't have time to correct ABAP, Test, get approval to move to Prod, and re run long programs to recreate IDocs? No Problem! Use IDocs Mass Update to correct values and send IDocs to partner to get paid. (You can recreate IDocs with right data later and send them to black hole).
- Production systems often involve working with many partners. Sometimes, partner developmental cycles don't co-inside with yours so you may be left with crippled interfaces that need manual IDocs updates daily. Sometimes you may have unwilling partners, or fixing a small issues won't get high enough priority from partners. I have personally spent many hours correcting IDocs manually everyday. Check with your production support teams and factor in their feedback. I kid you not, but some people enjoy doing manual repetative tasks, or no-value-added tasks.
- I am actually confident enough that if you haveIDocs interfaces, you will get ROI in in weeks if not months on this tool. You don't know how many hours you are wasting updating IDocs manually.
Caveat
1. This is an Expert Only tool, or at least for select few, just like WE09 in Production. Don't tell too many about this, or you will have people doing IDocs mass updates just because they can. That is why creating copies of originals, and periodically checking to make sure this tool isn't abused is very important.
I could easily clean up the code we have and put it here for others to follow. (Where’s fun in that? )
However, if SAP can do it, it will save us all extra effort. I am sure this can be done in less than couple of months by a good developer.
Please go ahead and leave a comment here and let SAP know you want to be able to analyze IDocs data en mass. Or prove me wrong and tell me SAP has something like this already. I hope you do the first one!
