SAP Experts: VMware Virtualization | Consulting | Integration - DataXstream
SAP Certified Consultants
In my last post on this topic, I discussed two negative effects of customizations in an upgrade project – risk and cost. I also discussed an obvious reason to eliminate unnecessary customization – the mitigation of risk and cost.
In this post, we will look at some of the customization areas which add risk and the cost to an upgrade project.
Recently, I was looking at a requirements document to build an interface to an external system that wants to query customer master data by the customer first name and last name. As I read this, there were a cacophony of thoughts, all demanding equal attention, racing through my head:
- How will I ever match the inbound interface parameter “Tom” with “TOM”, or “tom”?
- How will I ever match the inbound interface parameter “Smith” with “SMITH” or “smith”?
- The ABAP WHERE clause is not case-INsensitive.
- There could be hundreds of customers named Tom Smith.
- KNA1-NAME1 and KNA1-NAME2 are not indexed fields.
- And no, we are not storing any portion of either first or last name in an existing indexed field like SORTL.
- There are well over one million customers in the database.
- We have already decided to use PI for all interfaces.
- I will have to buy the BASIS team a case of beer to get them to agree to create indices on the fields KNA1-NAME1 and KNA1-NAME2 in a table with over one million records.
I arrived at the conclusion that I need a case-insensitive database query, along with database indices created for the fields KNA1-NAME1 and KNA1-NAME2.
But, what is a case-insensitive WHERE clause? A little research and help from colleagues revealed that many had gone before me, and this was nothing new. To implement a case-insensitive WHERE clause in ABAP, you simply needed to use the native SQL UPPER() construct. The database system that is being used is Microsoft SQL Server, but the UPPER() function and its syntax is similar across different database platforms. This seemed like an easy nut to crack. But, as I soon found out, I actually had a lot to learn.
[Read more...]
You may have heard the following idiom before:
Too many cooks spoil the broth
The common meaning extracted from this saying is that too many people working on a single task tend to make a mess of it. But, what happens when you have too many developers working in a single piece of ABAP code? That’s right, you get a big mess. This issue is especially difficult to deal with when there are multiple functional requirements leveraging the same custom code object, form-based user-exit, or function-based user-exit.
While current releases of SAP (those built on SAP NetWeaver 2004s and later) have good built-in handling of enhancements and customizations via implicit and explicit enhancement points and BADIs, there still exists many old-school user-exits.
I recently worked on a project where three separate developers were creating three separate interfaces based on the outbound delivery IDOC. While the development for all three interfaces was occurring at the same time, the go-live date for each of the interfaces were different (we’ll discuss that project management glitch at another time). Each interface required a separate set of custom fields and, therefore, it’s own IDOC extension. The problem is there is only one appropriate user-exit in IDOC_OUTPUT_DELVRY and three developers needed to be developing in it at the same time!
How did we solve this problem?
[Read more...]
It looks like it is official: 2010 is the year of the upgrade. A little validation is good for my self-esteem. Now that’s out of the way and I’m polishing my attaboy trophy let’s get on with it.
In this post I’ll do a combined discussion about the use of offshore resources in an upgrade project as well as share some experiences working with remote resources. My colleague, Mike Salvo, has already discussed ABAP customizations in an upgrade in this post. Now that you’ve found these customizations, what do you do next? Actually Mike provides loads of good advice about what to do next in terms of sorting out what is in the overall pile of objects that need to be examined.
What I hope is that you have documentation related to these objects: information that tells you why they were created, what they do, where SAP functionality is deficient in the current release and how you worked around the shortcoming. This should be helpful in making the evaluation about whether you can remove a particular object or if you need to make sure it works in the new release in a way that satisfies your business and/or technical need.
I going to assume that you have been through the “bag of rocks” analysis described in Mike Salvo’s posts and now have a collection of pebbles, stones and boulders to work through. This is where you can make good use of offshore resources to help out: there’s a lot of discussion about the use of offshore resources and you can use them really well or really badly. Let me digress.
In my last blog entitled What’s in a Namespace, I discussed the value of developing deliverable custom solutions in a reserved unique namespace. In this blog, I will discuss how a namespace is related to a software component. I will also discuss the typical product lifecycle, the software component version, and the convention which we use for establishing the software component version release increments.
DataXstream, an SAP Solution Partner, builds, packages, and distributes custom solutions for our clients. We develop all of our custom add-on products in our own reserved and unique namespace /XSTREAM/. But, we also need to reserve a separate unique namespace for each add-on product that we package and deliver using the SAP Add-on Assembly Kit. So, we have a single development namespace /XSTREAM/ and a separate “packaging and delivery” namespace for each add-on product. Why is that?
DataXstream, an SAP Solution Partner, builds, packages, and distributes custom solutions for our clients. We have built and packaged these solutions both in our own SAP landscape and in our client’s SAP landscape. In doing so, we must be careful about how we manage our namespaces, their associated development and repair license keys, and packages. It is not surprising, then, that I have received several inquiries asking about our namespace strategy for the development, packaging, and distribution of add-on products.
by Steve Park PI/ABAP consultant
Have you ever called a Web Service which is hosted by SAP just to get a generic return code that could mean anything? Do you wonder what was the exact data that was being passed in the parameter as it was executing the SAP web service? For example, when passing ‘00001’ is it really passing ‘00001’ or is it just passing ‘1’. This could be a difference between a successfully called web service or a web service call that brings back an exception.
I found an issue when testing an SAP web service when making a call from an external client. The SAP Web Service was sending back an exception to the external client that did not tell us much of anything.
This SAP web service was created from a function module so my first step was to go to the function module and input exactly what the external client tried to send and hoping to get the same exception. Surprisingly the function module came back successfully.
Since I could not figure out what was wrong when testing in SAP, my next step is to see what the external client is really passing real-time into the SAP Web Service by using the ABAP debugger. You are probably asking yourself, how in the world will SAP know when to initiate the ABAP debugger since SAP is being called from an external client?
The answer: You have to tell SAP that you are expecting a call
Here are the steps to activating the ABAP debugger for external calls.
1) In transaction SICF, find the service that you are having issues with and highlight your service then go to: Edit -> Debugging->Activate Debugging
2) Here you need to enter the user id that the external client is using when making the call. It is vitally important that it is the same user that you will be logged in SAP.
3) Make sure that you are currently logged into SAP with the same user. Now initiate the call from the external client and this time you will notice an ABAP debugger will be initiated as well. Now you can step through the code and see exactly where the problem is occurring.
4) Once you have found the problem, don’t forget to deactivate the debugger. If you forget, SAP will deactivate it automatically after a period of 2 hours.
