This is for those who are new to Web Dynpro programming. Here is an explanation of how to set up a Web Dynpro application using the context and binding the context to User Interface (UI) elements of the application. This is only a basic explanation to help set a foundation for understanding Web Dynpro programming. The 3 basic elements of a Web Dynpro application are windows, views and the context. The window is simply a container for a view. To assign a view to a window expand the views and windows under the section labeled ‘Object Name.’ Double click on a window and then drag and drop the view into the window. [Read more...]
It’s SAP Upgrade Time! Do You Know Where Your Customizations Are? Part 3.
In my final post on this topic, I will discuss some of the techniques that I use to “discover” information about customizations in an SAP system, even in the absence of any documentation. The information available to be discovered may include such details as the object name, object type, user name of the person who made the last modification, date and time of the last modification, usage statistics, where-used, and for code-based objects, even the versions and their code differences.
It’s SAP Upgrade Time! Do You Know Where Your Customizations Are? Part 2.
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.
Build an RFC Client with NCo 3.0 – A Step-By-Step Guide
The SAP .Net Connector 3.0 (NCo 3.0) offers many improvements over the 2.0 version of that product. Unfortunately, SAP no longer offers example .NET code. This blog attempts to fill that gap by describing how to build a simple RFC Client using SAP .Net Connector (NCo) 3.0. Click here to request a .zip file containing a copy of the source code.
The sample program displays details about companies defined by SAP. There are two BAPI calls involved, BAPI_COMPANY_GETLIST and BAPI_COMPANY_GETDETAIL.
Along with the SAP .Net Connector 3.0, we are using Microsoft Visual Studio 2010 and the Microsoft .Net Framework 4.0 to build our sample. Prior to starting, you will have to download and install NCo 3.0 (OSS login required).
[Read more...]
SAP Data Migration – Dealing With Fallout (Part 3)
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.
Why the data will not load correctly.
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:
- Poor quality legacy data.
Legacy systems which are not as tightly integrated as SAP, and are not under master data control allow the end user a bit of freedom when entering data. A zip code may contain too little or too many characters; the email address is not properly formatted; numeric fields have transposed digits; various forms of abbreviations (especially in the city field), a quantity of zero (0) permitted by the legacy system and uploaded into a field where SAP will not accept a quantity of 0 and even simple misspellings all can cause stringent validation checks to trigger an error and prevent the record from loading at all. A more sinister type of error occurs when the data is functionally incorrect, but good enough to pass all of the SAP validity checks. In this case, the data record will technically load into SAP, but will not be functionally correct. Duplicate customers, duplicate vendors, and the data entry error for a quantity of 1000 instead of 100, and the wrong pricing condition applied to a sales order line are examples of this scenario.
- Functional configuration and supporting data effects.
Many times I have watched the load statistics for a data object plummet from near 100% in the cycle two test load to near 0% in the cycle three test load. This is very unnerving to the client because the cycle three test load is getting rather close to the go-live date, and “by the way, shouldn’t the statistics be getting better rather than worse?” Functional configuration changes can wreak havoc on any data load. Flipping the switch on a data field from optional to required; turning on batch management or serialization for materials for the first time; changes in the handling of tax, tax codes, and tax jurisdiction codes; that account determination entry that is missing or not set up correctly; a missing unit of measure or unit or measure conversion factor; the storage location in the upload file which does not exist in SAP – any of these can cause a load to drop mostly or completely onto the floor.While change is inevitable on any project, it is important to control and communicate the change so that the downstream impact can be recognized and understood. Controlled change and communication always works better than total surprise. Perhaps if we all know ahead of time about that data field that is now required, we can impose a requirement on the data extract side to make sure that the data field is populated before it enters the upload file. - Additional data in the upload file.
Inserting a new field in the middle of the upload file data structure might be necessary for the business to close a gap, but if that change is not communicated to the technical team so that appropriate adjustments can be made to the load object’s input structures and processing logic, the new data will surely never load, and may cause misalignment of the data fields which follow it in the upload structure.
Coming Soon: SAP .NET Connector (NCo) 3.0
SAP is announcing a new version of SAP Connector for Microsoft .NET 3.0 (now called “NCo 3.0″). A beta program for selected customers and partners is currently underway (Q3, 2010) with the general release of the software coming soon thereafter. I will highlight some of the major differences between the SAP Connector for Microsoft .NET 2.0 and NCo 3.0 (besides the obvious, and much-needed name-shortening).
EDITOR’S NOTE: NCo 3.0 has now been released. Read more details here.
SAP Data Migration – Answering the Important Questions (Part 1)
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!
Using Native SQL in an ABAP Proxy
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...]
The Art of Writing an SAP Functional Specification
Overview
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.
Too Many Developers Spoil The Code
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.
Multiple Developers; One Code Object
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...]
