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.
One of the inevitable aspects of data migration is dealing with fallout from automated data loads. Typically, this process includes identifying the data that will not load, analyzing the error messages to determine the root cause, formatting a readable report that can be used as a tool in the cleanup process, and fixing the root cause of the problem so that it does not happen again.
There is a litany of reasons why some data records will load correctly while others will not. Here is a list of some common root causes:
It is data migration time on your SAP business project. Whether your project is implementation, acquisition, or merger, the goal is pretty much the same: the seamless inbound acquisition of master and transactional data from one or more external data sources while ensuring that this activity has minimal impact on the rest of the business. This is where we attempt to move years of neglected master and transactional data from a loosely structured, anything-goes legacy system into a very tightly integrated and highly structured SAP system. You must consider the likelihood that the concept of master data management had not been invented yet when the legacy or source system providing your data was implemented.
How much data to move? How much data to leave behind? What to automate, and what to execute manually? How to gracefully orchestrate and execute a data migration cutover from one system to another? Where and how to fit the data migration plan into the overall business implementation plan? How to continue to run the business during the data migration phase of the business project implementation? These questions are all part of the planning fun!
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...]
I am currently working on an SAP implementation project that is just starting its realization phase. One of my first tasks, as a member of the technical implementation team, is to review completed functional specification documents for RICEF objects. These documents, written by functional subject matter experts, are supposed to detail business requirements that address gaps, and which need to be incorporated into the system being implemented. The purpose of the review is to make sure that the functional specification documents are complete, accurate, and contain the approval signatures required to move on to the technical design phase.
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.
This blog post describes step-by-step how to use the SAP .Net Connector and Microsoft C# to create an SAP RFC Server. This allows an SAP process to call your custom C# code, which can accept parameters and return values.
The SAP .Net Connector simplifies creating C# programs that can interoperate with an SAP host. The SAP .Net Connector is available from the SAP Service Marketplace. You must have access to the SAP Service Marketplace to be able to download the SAP .Net Connector. The SAP .Net Connector must be installed on your development machine before we begin.
RFC is a Remote Function Call. In this case, the SAP process is a ‘client’ that is making an RFC call to our custom ‘server’ code. Our code uses the SAP .Net Connector to register on an SAP Application Gateway.
The TLA system we have been creating exists solely to demonstrate certain programming techniques involving the SAP .Net Connector and C#. We will cover three separate parts of the solution: defining the function to SAP, creating a proxy object used to access SAP, and creating our C# code to perform the RFC function.
I love ALE. It is super-powerful and, once you get the hang of it, is a snap to configure. Recently, I was setting up an HRMD_A interface for my client. Everything was going smoothly until I ran into a requirement to filter out the social security number (PERID), birthdate (GBDAT), and gender (GESCH) for privacy reasons. All of these fields are in segment E1P0002. Initially, I thought that this requirement was easy enough to accomplish. I just created a IDOC reduction in transaction BD53 and filtered out the three fields. I soon found out that while entire segments were getting reduced from the IDOC as configured, the individually reduced fields were still showing up in the IDOC. What’s going on?!?
[Read more...]
By: Thomas Nittmann
Description:
This article focuses on practical techniques used to assist in the debugging and resolving workflow issues
during the development and production support phases of SAP implementations. The SAP Workflow
application incorporates the use of several components, i.e. graphical editing tool (workflow builder),
some object orientated concepts (use of the Business Object Repository), ABAP, and a hook/trigger
mechanism into one of the SAP application modules (FI, CO, MM, etc). As business requirements are
mapped into a workflow process definition and prototyping starts, debugging becomes an essential tool
to expedite the implementation of workflow process.
Q2Q3Y6XJM37U
