Let’s say that Customer 15 in your SAP system buys products from your company.  It sends inbound EDI Orders to you using three different partner IDs because they have 3 internal divisions and they want all transactions to be separate.  You want to keep all sales data for this customer under one customer number in your SAP system and just separate them by a different division.  You are required to send out EDI invoices to this customer, but they must go to the correct EDI Partner ID.  Let’s say you would normally use the Standard SAP Output Type RD00 and  Access Sequence 0003 (Sales Org, Distribution Channel, Division, Customer Number) for producing your INVOIC IDOCs.

Your first step would be to make three copies of the RD00 Output Type (ZRD0,  ZRD1, ZRD2) using transaction V/40.  We will need to make three copies because the Standard RD00 Output type uses Access Sequence 0004.   Select Change mode for this transaction and find the RD00 entry.  Select the RD00 entry and click on the ‘Copy As’  icon on the Menu bar or press the F6 key.

Change the Output Type to ZRD0 and the Access Sequence to 0003 and hit your Enter key.

A prompt will appear with three options.  Copy all, only copy entry, or cancel.  Select the copy all option.

An information message will appear displaying the number of dependent entries have been added.

Hit the enter key and the main Output Type screen will appear with your new output type.  Select the entry and double click the Processing Routines option in the left hand column.  Make sure that the EDI Medium is listed under the Processing Routines.  If not, add it as shown below.

Double click on the Partner Functions option in the left hand column.  Make sure the Partner Function you will be using is listed for the EDI Medium.  In this case we will be using the BP (Bill-to Party) Partner Function.

Hit the save button to save the new output type.  Repeat this process for the other two new output types.  If the Access Sequence you require is not available a new one can be created.  Creating a new Access Sequence is not covered in this blog.

Now we can set up the Partner Profiles for this customer using transaction WE20.  On WE20, expand the Partner Type KU folder and select customer number 15.  Under the Outbound parmtrs section click on the ‘Create Outbound Parameters’ icon.

Fill in the proceeding screen with the as follows.  If you are using an IDOC Extension enter that also.  For this example we are just using the Standard INVOIC02 IDOC.  As you can see I have entered 10 in the Message Code field.  This represents one of the Divisions for this customer.  You can use this field and the Message Function field to differentiate between Divisions or other criteria you wish to use.

Select the Message Control tab and click on the Insert Row icon.

Your Application will be V3 (Billing), your Message Type will ZRD0 (the new output type), and your Process Code will be SD09 (Invoice).  Enter these three values and save the entry.

You will create two more Outbound Parameter entries for the other Divisions.  In these two new entries you will place the other divisions in the Message Code field and the other output type field in the Message Control Message Type field.  Everything else will be the same.

When you are done, the Partner Profile for this customer will look like this.

Finally we will need to create the output determination so the output is created automatically once the invoice is completed.  For invoicing, the transaction for output determination is VV31 for create and VV32 for changes.  We will use VV31 since this is the first time this output type will be used.  Enter ZRD0 as the Output Type and hit Enter or click the Key Combination button.  If more then one Key Combination is available then a pop up window will appear asking which one you want to use.  Once you select one and click the Green check the key fields will appear.  If there is only one, then the key field will appear immediately.  Select the SOrg/Distrib Ch/Division/Customer option.

Enter the Sales Org, Distribution Channel, and Division data.  Then for each customer you will be using this Output Determination for you would enter the Customer Number, Partner Function, Medium (6 = EDI), Date/Time (This represents when/how the output will be processed), and Language (EN = English).  Then hit the save button.  Repeat this process for the other two output types.

Once this is completed every time an invoice is created for this combination of Sales Org, Distribution Channel, Division, and Customer number an Output will be created using the specified Output Type.  Once the output is processed an IDOC will be created with the Division in the Control Record of the IDOC which can then be used in the EDI Software to determine which EDI Partner the data should be sent to.

How do you convert these external customer numbers into your internal SAP customer numbers?

Some may hard code these conversions into their EDI maps.  This approach can be very high maintenance as customers can add new ship-to locations or reorganize their internal numbers which would require changes to your maps.

Others may set up a cross reference table within their EDI translation table to perform the conversion.  This works well at times, but then you are at the mercy of your EDI group to update the table with any new additions or changes to existing entries.

I find the best way to perform this conversion is within your SAP system.  Mainly because SAP has given you a standard utility to perform the conversion.  All you need to do is populate a few fields of the incoming IDOC and populate the EDPAR table using transaction VOE4 with the internal and external customer numbers.  The Function Module used to process the IDOC takes care of the rest.  SAP uses the Sender Partner Number of the IDOC Control record along with the PARVW and LIFNR elements from the E1EDKA1 segment to look up the correct entry in the EDPAR table.  In your EDI maps you would populate the PARVW element with the partner function code for the external customer number (AG = Sold-To, WE = Ship-To) and populate the LIFNR field with the external customer number received in the EDI file from that partner.  All other fields would remain blank in the E1EDKA1 segment.

Sender Information Partner Number from the Control Record:

E1EDKA1 Segment for the Sold-To Partner (AG):

E1EDKA1 Segment for the Ship-To Partner (WE):

Use transaction VOE4 to populate the EDPAR table.  You enter the value from the Sender Partner Number in the IDOC control record in the Customer field, the function code for the partner in the Ext. Function field.  Note: The Ext. Function field will not be the same as the Partner Function (PARVW) element of the IDOC.  (AG in IDOC = SP on VOE4, WE = SH).  The External Partner is the number received in the EDI data from the customer which is also the number in the LIFNR element of the IDOC.  Int. no is the SAP customer number associated with the External number.

VOE4 transaction with required entries for the Sold-To and Ship-To for IDOC information above:

Using the EDPAR table for customer conversion allows this function to remain in control of those responsible for customer accounts.  Users can be trained to use the VOE4 transaction to update the EDPAR table so when new ship-to or sold-to numbers need to be added they can be done in a timely matter and not rely on other departments.  It also takes this responsibility away from the EDI group so they don’t have to maintain maps or tables for this function.

This function can be used for other incoming IDOCs as well.  You will need to check the Function Modules used to process incoming IDOCs to determine if EDPAR can be used for customer number conversion and on which IDOC segment you would send the external number.

Outbound IDOCs can use either the EDPAR table or the PUMA table to cross reference external customer numbers.  Again, it depends on the IDOC type.  I will cover this topic in a separate blog.

For the element that’s text cannot be hardcoded or the element that’s visibility needs to change during runtime, the context needs to be used. The data that is seen on the screen is not stored within the web browser itself. The Web Dynpro application makes calls to the server to retrieve data to be displayed. This is where the context comes into play. The context is the memory on the server that stores data for the Web Dynpro application. When setup correctly a context can hold tables, structures or single element variables. Here is an example of how to build a context and then make method calls to read or set the context.

Select the ‘Context’ tab. Right click on the context node and select ‘Create’ -> ‘Node’ and fill out the fields according to the picture below.

Right click on the BUTTON_PROPERTIES node and select ‘Create’ -> ‘Attribute.’

Now we have created an attribute in the context that will hold a string value. By the names I have given to the node and the attribute you can guess that this node will hold any attributes related to the button we created. The attribute that we created will be used to hold text value of the button.

Now that the context attribute has been created, let’s fill it with a value. Go back to the button properties under the ‘Layout’ tab and find the ‘onAction’ properties under ‘Events.’ Click the create button, it looks like a white piece of paper with the top right edge folded down, and fill in the fields as below.

Double click on the name of the new action we just created, SHOW_TEXT and this will take you to the methods tab. Here we are going to use the Web Dynpro Code Wizard to set the value of the attribute.
Click on the Web Dynpro Code Wizard icon (or Ctrl +F7), select ‘Read’, click and select the attribute that was created, TEXT. (Illustrated Below)

Now repeat the same steps starting with the Web Dynpro Code Wizard except this time select ‘Set’ instead of ‘Read.’ Each time the Web Dynpro Code Wizard is used DATA variables are created.

Note: If there are multiple attributes within a node, all of the attributes can be read or set at once by selecting the node.

After using the Web Dynpro Code Wizard the second time we now have two copies of the data variables that will not compile. Select the second set and delete them and in place put the following code:

Now if the application was tested the value of the attribute TEXT would be changed  between ‘Hide Text’ and ‘Show Text’ every time the button is pushed.

That is the rundown of how to build, read and set the context’s nodes and attributes. Now the context needs to be linked or ‘bound’ to the UI elements. Go back to the Layout tab and select the button. Under the properties find the ‘Text’ property. Click the yellow box to the right of the property and select the attribute to create the binding .

Binding

Binding is linking the data in the context to the UI elements. Here we have created an attribute that holds text. The ‘Text’ property of the button is set to the value within that property. Activate the Web Dynpro Component, create an application and test it.

For a little extra practice, add a TextView by dragging and dropping into the layout or right clicking on ROOTUIELEMENTCONTAINER and selecting ‘Insert Element.’ In the properties section set the Text value to ‘Now you see me!’ Create another node and attribute for the TextView by going to the ‘Context’ tab and right clicking on the ‘Context’ node and selecting ‘Create’ -> ‘Node’. Then create the attribute with the properties below.

Go to the ‘Methods’ tab and go into the method we was worked on earlier, ONACTIONSHOW_TEXT. Place the cursor after the ‘if’ statement that was put in, approximately line 33. Use the code wizard to set the new context we made. Then cut and pasted the DATA declarations just created and move them up to the top of the code. Then edit the ‘if’ statement to look like this:

Return to the ‘Layout’ tab, select the TextView and set the ‘Visible’ property to the new attribute. Activate the Web Dynpro Component and test the application.

The SAP .Net Connector 3.0 (NCo 3.0) offers many improvements over SAP .NET Connector 2.0. 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 with VB.NET.  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).

Setting up the Project

Using Visual Studio 2010, create a new Windows Form project. In the project properties, be sure to set the Target Framework to .Net Framework 4.0.  To change the target .NET framework version on a VB.NET project, first open the project’s property page.  Click on the “Compile” tab in the property page.  Then click on the “Advanced Compile Options..” button.

In the ensuing dialog window, change the target framework version.

Next, add references to the SAP .Net Connector 3.0. There are two DLLs, sapnco.dll and sapnco_utils.dll.

Design the Form

Add two controls to the form. The first is a List Box, which will contain the list of available SAP companies. The second control to add is a Property Grid control, which is used to display the details of a particular SAP company when the user selects one from the List Box.

Using App.Config to define the SAP Connections

There are several methods you can use in your solutions to define a particular SAP host. For this example, we are using an app.config file to define our SAP host.
The SAP .Net Connector 3.0 includes sample app.config files. For the RFC client, be sure there is a sectionGroup definition for <ClientSettings>.
The SAP host is defined by the destinations section. Within the destination, the Name field identifies this app.config entry to our program code. Specify the appropriate user name, password, SAP host name, client and system number in the destination section.

The BAPIs

Use the SAP transaction SE37 to determine the parameters for functions BAPI_COMPANY_GETLIST and BAPI_COMPANY_GETDETAIL. This will tell us what parameters need to be passed in and where to find the results that are returned to our code.

The Code

During the form load event, we want to populate our List Box with the defined companies from SAP.

1. Acquire a valid RfcDestination to use. Use method RfcDestinationManager.GetDestination() to do this. GetDestination() requires a parameter to determine which SAP host to refer to. Pass in the Name of the SAP host you previously defined in the app.config file. (Line 39)
2. Now that we have a valid RfcDestination object, we need access to the SAP Repository. The repository contains information about the BAPI calls we are going to make. The RfcRepository is an attribute of an RfcDestination object. (Line 42)
3. Using the RfcRepository object, acquire a reference to the SAP BAPI by calling method RfcRepository.CreateFunction() method. Pass in the name of the desired function as a string parameter to CreateFunction(). This method returns an object we can use to setup parameters, invoke the function, and retrieve results.
4. Now we can make the RFC calls into SAP. Using the IRfcFunction object returned by CreateFunction(), call the Invoke() method, passing in our RfcDestination object as parameter. This will make the RFC call into SAP, and provides the results via our IRfcFunction object. (Line 48)
5. SAP function BAPI_GET_COMPANYLIST returns a table of company records. We use an instance of an IRfcTable object that we retrieve by calling the GetTable() method on the IRfcFunction object. To get a desired table, pass in the table name to the GetTable() method. (Line 50)
6. We now have an instance of an IRfcTable object that contains company information through which we can iterate. It is possible to iterate through the data by setting the CurrentIndex property on the returned table. For a particular row in the table, it is possible to access values using the GetString() method. (Lines 55-59)
7. For each company, get the CompanyNumber, and use that as a parameter to SAP function BAPI_COMPANY_GETDETAIL. BAPI_COMPANY_GETDETAIL returns detailed information about that particular SAP company. The techniques are the same as before, with the additional step of using the SetValue() method on the IRfcFunction object to pass in the company number as a parameter. (Lines 60-67)
8. BAPI_COMPANY_GETDETAIL returns data as an instance of the IRfcStructure interface. Access individual field data of the company record, using the GetString() method of the IRfcStructure object instance. (Lines 67-78)
9. Extract the company details as desired. Add them to some object you create and then add that object to the List Box control. (Line 80)

The rest of the code is regular Windows Forms programming. Your code will need to wire up the List Box changed events so that the Property Grid will display the details of the selected company.

Additional Information

Follow these links for more information about NCo 3.0 programming:

• Webinar: SAP NCo 3.0 – Best Practice Guide for Upgrade from .NET Connector 2.0
• Source Code: RFC Client with NCo 3.0 for VB.NET
• C# version of this example: Build an RFC Client with NCo 3.0 – A Step-By-Step Guide

Discovering Direct Modifications of SAP Standard Objects – One Example

As I discussed in a previous post on this topic, direct modification of SAP standard objects within the SAP namespace carries a high risk in an upgrade project.  It would be very valuable to be able to identify some details about these objects, so that further analysis could be performed to determine their disposition in the upgrade.

Modification of standard SAP objects typically requires that a modification registration key be obtained for that object from the SAP SSCR facility.   The SSCR facility (SAP Software Change Registration) is a procedure which registers all manual changes to SAP sources and SAP Dictionary Objects.  With a valid and authorized OSS ID for an SAP system, you can go to the SAP Support Portal on the web and view the SAP objects that were registered for modification by that OSS ID.  If there are multiple OSS IDs for any SAP system, make sure that you check all of them to capture all objects registered by all of the authorized OSS IDs for an SAP system.  Press the “Objects Registered by Me” button to view a list of the registered objects.

Another place that you can look for this information is directly within SAP.  Table ADIRACCESS stores the registration keys which were obtained from SAP, and which were entered by the developer when the object was to be modified for the very first time.  This entry shown below from table ADIRACCESS shows that function group SCPRPS was registered with SAP for modification.

Registering an object for modification does not mean that the object was actually modified.
What additional evidence can we discover that would show that the object was, in fact, modified?   And, since a function group contains many objects, can we determine exactly which object or objects were modified?

With a little bit of forensic analysis, we can discover the specific object within the function group that was modified, the user name of the programmer who last modified the object, date of the last modification, and the line-by-line source code differences.

If you are familiar with the structure of function groups, you already know that they may contain many function modules, and that the source code for each function module resides within its own include file.  At the moment, we know that the function group name is SCPRPS, but we do not have the list of function modules within that function group.

To obtain that list, we can use the SAP function module FUNCTION_SELECT_TFDIR.
The result list is shown here:

So which, if any, of these has been modified?  To determine this, we need to find all of the rows in table TRDIR where the NAME field is equal to the PNAME entries listed above.

Here is an excerpt from SAP table TRDIR for SAP object names that begin with the characters LSCPRPSU:

Note that for all of these objects, which are not in the customer namespace, the Author Username field (TRDIR_CNAM) is ‘SAP’.  Also note that for most of the entries listed here, the Last Changed By user name field (TRDIR_UNAM) is also ‘SAP’, except for one row, where the Last Changed By username field is not ‘SAP’.  From this row, we can see that include file LSCPRPSU36 was last modified by user DXSDEV on 10/19/2009.

If we look back at the result list of FUNCTION_SELECT_TFDIR and find the row where the field PNAME is equal to LSCPRPSU36, we can see that the name of the modified function module is SCPR_PRSET_CT_IMPORT_INDUSTRY.

Exactly What Changes Were Implemented?

By going to the Version Management Utility for this function module, we can see what the various versions of the code contained.  The Version Management Utility will also show us the transport request numbers, date and time, and username for each version of the code.  The Version Management Utility also has a code comparison tool which will highlight the line-by-line differences between versions of the source code.

Here is an excerpt from the side-by-side source code comparison utility which shows the modified version on the left side and the original version on the right side.  Fortunately, in this instance, the programmer left excellent notes indicating that a correction instruction from an OSS note was being applied.

What Are the Discovery Possibilities?

The manual example described above showed how to discover and analyze customizations that had been applied to a single SAP standard object.  But what if the customizations number in the hundreds or even thousands?  What about all of the customizations that were built entirely within the customer namespace?

It is possible to discover hundreds or even thousands of customizations regardless of which namespace they were developed in.  The key is automation, understanding that this information already resides within SAP waiting to be discovered, and more importantly, understanding the meaning of the discovered information.  I have already developed an ABAP discovery program which will mine, analyze, and report data about the following customized objects:

More Discovery – Usage Statistics and Where-Used

Customization Usage Statistics

The goal of customization usage statistics analysis is to discover the usage frequency of customized objects.  The usage discovery may show usage anywhere from several times daily by key users, to none when analyzed over a long time period.   Since most companies really do not want to incur the cost and the risk of moving an unneeded customization into the upgrade system, objects which show no usage over long periods of usage history become targets.  Care must be used here, as some transactions are exercised only quarterly, semi-annually, or annually.  I always recommend letting the business process owner make the final decision to eliminate any customization object in the upgrade.

SAP keeps track of usage statistics, and this data is available for you to analyze.  You will need to check what facility is available for your particular SAP system, as the transaction codes and programs differ among various versions of SAP.   The amount of data stored within SAP is configurable, and is usually set to a small date range.  Some companies that want to analyze the statistics over longer time periods actually download and store the statistics data in their own external databases.

Customization Where-Used

Like usage statistics, the goal of customization where-used analysis is to discover customized objects that are orphan or not being used.  What about that custom data type that is not used in any table or structure?  What about that function module that shows an empty list when you click the where-used icon in the function builder?

To properly perform a where-used analysis, it is important to understand all of the various possible uses for an ABAP object.  For example, here is the selection screen of possible uses that is presented by the ABAP Dictionary when you click the where-used icon to determine the where-used list for a data table:

And what about that custom function module, which I alluded to earlier, which shows a completely empty where-used list?  Perhaps it is a remote-enabled function module that was installed by, and is currently being called by an external third-party package.   Or, perhaps it is linked to an SAP EDI inbound or outbound process code.  It is really important to be able to properly interpret the data being presented and to not draw any hasty conclusions.

ABAP Programs Where-Used Analysis Example

In the ABAP workbench, SAP provides a where-used facility, which reports the various areas where a single selected object is used.  For a discovery project, you may want to automate this facility to analyze groups of ABAP objects (e.g. all custom ABAP programs, all custom tables, etc.).

Here is an ABAP programs where-used analysis example to help illustrate how a where-used analysis might be utilized.

Your automated where-used analysis program to analyze custom ABAP programs reports fifteen custom programs which show no usage in any of the following areas:

A quick analysis shows that all of these fifteen programs are simple reports.  Since users typically execute their reports via transaction codes, you wonder how these fifteen programs could ever possibly be executed without transaction codes.

You further analyze the SAP job scheduler data as far back as possible and find that only ten of these ABAP programs were ever scheduled in a batch job.  Some of these were scheduled very recently, and some have not been scheduled for a long time (another thread of evidence that we will need to pursue).  This leaves five ABAP programs with no apparent means of being executed.

As further evidence, you perform a cross-check against the usage statistics report and find that two of these five ABAP programs show no usage.

Armed with this analysis, you are now ready to meet with the business process owners to discuss the disposition of the objects on your short list.

A salient point here is that you will need to gather your evidence from several different analysis sources to help paint the most accurate picture about the possible disposition of customized objects.

Summary

Throughout all three parts of this post, I have stressed that customizations, while necessary, add risk and cost to an upgrade project.  And customizations that are not necessary or built poorly without the constraints of best-practice controls can add high levels of risk and cost.  Here are some general guidelines to follow:

Many companies and their auditors consider a well-controlled and secure ERP system to be a fundamental component that is vital to the success of the business.   They recognize that an out-of-control ERP system can easily paralyze a company for extended periods of time.  With this in mind, implement and enforce best-practice controls and standards to make sure that future customizations are reviewed, approved, built, tested, documented, and implemented properly.  This may already be an internal or external audit requirement, so check with your inside and outside auditors to make sure that your controls meet the auditing requirements.

Periodically review, audit, and amend your best-practice controls to make sure that they are still effective in supporting the needs of the business; and that both internal staff and external consultants are in compliance of these controls.

Know your customizations.  Know where they are, why they are, and what they do.  Whenever feasible, it is most efficient to eliminate ABAP object customizations, especially any that were performed within the SAP namespace, and any that are not really needed because they can be implemented within standard SAP.

The degree of risk and cost depends on the specific type of customization that was performed.  Establish a formal review board to own the customization approval process.  Understand that approving a customization also means approving the risk and the cost burdens.  Some companies consider this to be so significant, that they include a high-level business executive as a default member of the review board.

Set and enforce a policy making ABAP object customization the last resort, only after all other options have been thoroughly researched and exhausted.  Here are some examples:

1. Research forums, blogs, become active in user groups, etc. to see how other companies might also be implementing the business function that you require.
2. Find and use customer and user exits instead of directly modifying objects in the SAP namespace.
3. Determine, for example, how to implement and maintain that complex pricing procedure using the pricing condition tables instead of writing custom code and building custom tables.

Share Your Experience.

Once again, I look forward to hearing from our readers to reply to this post with their own experience with customizations, best-practice standard and policies, and success stories illustrating how your company transitioned to best-practice controls.

[Editor's Note] This blog is third of a multi-part series:

1. Part 1
2. Part 2
3. Part 3

In this post, we will look at some of the customization areas which add risk and the cost to an upgrade project.

1. Direct Modifications to SAP Standard Objects

Direct modifications to SAP standard objects bear the highest risk.  During the upgrade, these modifications will be lose–either because they will be overwritten by their respective upgraded SAP standard objects; or because these objects no longer exist and are not used by standard SAP in the upgrade system.

Typically, there are two reasons for performing direct modifications to SAP standard objects:

1. The application of authorized individual OSS corrections to fix problems.
2. Direct customer modification to provide business process enhancements.

1.1. Application of Individual OSS Corrections and Support Packs

Individual OSS corrections are patches supplied by SAP to fix recognized problems with SAP objects.  Sometimes, individual OSS correction instructions are included and delivered within a specific level of support packs.   That means that applying support packs to the specified level will apply the desired correction, and manual intervention is not needed.  Sometimes OSS correction instructions are not yet included in any specific level of support packs, and these will need to be applied either manually or with the SAP Note Assistant.

It is important to carefully analyze the validity range of an OSS note to determine both how it was applied in the legacy system, and how it is to be applied in the upgrade system.  This analysis will help determine how far to patch the upgrade system to make sure that the desired corrections are included in the upgrade system.   Any needed correction that exists at a patch level beyond the highest patch level in the upgrade system will need to be addressed  manually or with the SAP Note Assistant.

The decision of which support pack levels should be applied to the upgrade system must be made carefully.  One approach is to apply the highest level of support packs that are available.    The rationale for applying the latest available support packs is to insure that the most recent problem fixes are applied to the upgrade system.  This is a two-edged sword, as the most recent  support packs may also introduce other problems into the upgrade system.

1.2. Direct Customer Modification of SAP Standard Objects to Provide Business Process Enhancements

Direct modifications of SAP standard objects to provide enhancements are most costly and bear the highest level of risk.  While direct modifications of SAP standard objects may have been technically expedient at the time of implementing the enhancement, they will always require additional work effort and analysis at upgrade time to determine:

1. Whether or not the functionality provided by the enhancement is still required by the business.
2. Whether or not the functionality provided by the enhancement is already included in the upgrade system as standard SAP.  You will need the help of functional subject matter experts here.
3. Whether or not the modified SAP object still exists in the upgrade system.
4. How to move these required enhancements into the customer namespace, using the SAP preferred enhancement procedures.  Moving these types of enhancements to the customer namespace also moves them from the very costly and highest risk category to a lower cost and lower risk category.

2. Custom Interfaces

Custom interfaces are loaded with opportunity for high upgrade risk.  Take, for example, the SAP standard IDOC Basic Type, which was copied as the baseline for an enhanced customized basic type containing additional custom segments and fields.  In the upgrade system, a new version of this SAP standard IDOC Basic Type may now contain additional segments and fields.

Likewise, the associated standard processing module for that standard basic type, which was copied as the baseline for an enhanced processing module to handle the custom segments and fields of the enhanced custom basic type, may also have changed in the upgrade to accommodate the new standard IDOC version.

So, in the upgrade system, especially if you need to implement the new upgrade IDOC version, it may be necessary to start with the new standard basic type and standard processing module, and reapply the customizations.

3. ABAP Code Objects

Of all customized objects discovered in most SAP systems, ABAP Code objects are the most numerous.  These objects include classes, methods, function modules, report programs, dialog programs, and include files which support the all of the other ABAP object types.

At greatest risk are the SAP standard ABAP code objects which were modified directly in the SAP namespace; and those that were copied into the customer namespace and subsequently modified. This is because the standard SAP code objects may have changed in the upgrade.    These changes can range anywhere from simple error corrections to complete process and code redesigns.  In these instances, each modified object must be compared to its counterpart in the upgrade system to determine its existence, and the nature and extent of what might have changed.   If the customization is still needed in the upgrade system, and to stay current with the enhanced standard code, it is probably best to start with the upgrade standard code and reapply the customizations.

ABAP code objects that were developed entirely in the customer namespace (not copied from standard SAP code) are usually low on the risk ladder.  Problems occur when data selected by these objects has moved elsewhere or behaves differently in the upgrade system, when ABAP constructs used are now obsolete in the upgrade system, or when standard called functions are changed in the upgrade system.

Ultimately, the business must decide why SAP standard code was directly modified, why SAP standard code was copied into the customer namespace and modified, why custom code was developed entirely within the customer namespace, whether or not any of these modifications are needed, and how they might be implemented differently in the upgrade system.  This evaluation presents another opportunity to remove some rocks from the customization rock bag.

4. Automated Standard SAP Transactions

Custom ABAP programs which automate standard SAP transactions bear an above-average risk.  This is because the behavior of some SAP transactions may have changed in the upgrade.  These changes can be manifest in the functional performance of the transaction, the technical location and existence of data fields on screens, screen field properties, IMG configuration specific to the transaction, the transaction code associated with the transaction, or even the existence of the transaction or an equivalent in the upgrade system.  The nature and the extent of the changes to the transaction in the upgrade system will determine the amount of effort needed to automate it.

Also, if an “old” SAP transaction has been replaced by a “new” upgraded equivalent, it is usually wise to make the change to the new transaction at upgrade time.  At some point in the future, the “old” version of the transaction will become obsolete and no longer useable or supported.

5. Data Dictionary Customizations

Many customizing projects within SAP require the storage and manipulation of data that is not included in the standard SAP dictionary.   One way in which these requirements can be addressed is by building complete custom transparent tables and data structures.  Another way is by adding append structures and append fields to existing standard SAP tables.  With either approach, it is always an excellent idea to evaluate the need to move these customizations into the upgrade; and another opportunity to lighten the customizing bag of rocks.

6. Customer and User Exits

Customer and user exits are provided by SAP as the SAP-approved mechanism for enhancing standard functionality.  Enhancements performed within these boundaries are guaranteed by SAP to bear low technical risk in an upgrade situation.  While SAP guarantees that the custom code will arrive technically intact in the upgrade system, functional analysis must still be performed to determine the continued need for the enhancement in the upgrade system.

Any enhancement implemented in a customer or user exit that is either functionally covered or determined to be unnecessary in the standard upgrade system should be retired.  This is consistent with the goal of lightening the load in the bag of rocks.  Since a customer or user exits may implement several different enhancements, take extra care to make sure that only the right code or other objects are retired.

7. The Environmental Effects – Operating System Change

OK, changing the operating system during an upgrade project is not customization of SAP objects.  But it does add risk and cost to the project.

Why?

If the upgrade operating system changes from UNIX to Windows or vice versa, then any ABAP program or interface which reads or writes a data file to an operating system folder must be changed.  The changes needed to these ABAP programs are very narrow in scope,  and reflect the manner in which the operating system specifies its file paths.  Additional BASIS work, such as determining the proper file system authorizations, may also be needed.

Using the SAP logical file name facility can help enormously by removing the need to make changes to hard-coded file names and path names in many different ABAP programs.

Share Your Experience

At the top of this post, I stated that I would discuss some of the customization areas which add risk and cost to an upgrade project.  I look forward to hearing from our readers to reply to this post with their own experience with customizations, how they were handled, and how this affected an upgrade project.

In my next post on this topic, I will reveal some of the techniques I use to “discover” customizations, even in the absence of documentation.

[Editor's Note] This blog is the second of a multi-part series:

1. Part 1
2. Part 2
3. Part 3

One such example of additional functionality is the ability to enhance delivered integration content.

Recently, I had to make some modifications to an integration scenario where an SAP ERP system was sending data to an external custom solution.  The good news was the SAP ERP and PI objects were built and delivered by SAP!

SAP ERP Delivered Content

The bad news was that the interface, as designed, did not meet the business’ need…

How to add fields to delivered content?

So, the $64,000 question is, how do we add fields to delivered SAP PI content?

SAP PI Data Type Enhancement

SAP PI data type enhancements allow developers to customize delivered SAP PI content.  Here’s a quick rundown of how it works:

Step by Step SAP PI Data Type Enhancement Instructions

1. First, create a new data type enhancement in the SAP PI ESR:
   
2. Add the required fields to the required data elements and then save and activate your SAP PI changes.
3. The newly created data elements are now in message type:
4. Login to the SAP ERP system and activate the proxy changes via transaction SPROXY.  This will create/update the proxy structures that correspond to the newly created data elements in the ERP system:
5. Finally, create a BADI to populate the new data fields in the SAP ERP system:
   
6. Save and activate your ERP changes. Now you’re ready to rock and roll!

SAP PI data type enhancements blends the stability and functionality of delivered content with the flexibility of custom development. It is definitely one of my favorite advances in the SAP PI platform.

After I stopped laughing, I started to cry, because I realized that this happens all the time in SAP PI–it just looks a little different…

However, most of the time complex mappings can be simplified by using a different approach.  The mapping block FixValues is a great tool to reduce needless. So let’s expand on this example.

Reducing Complexity with FixValues Mapping Block

Let’s say I am developing an interface between a database with information about goods/materials  and a file for system that needs the database data in an easy to read format. To help visualize here is some pseudo-XML of the database:

<Database>
  <row>
    <goodName />
    <goodType />
    <goodQuantity />
  </row>
</Database>

And here is some pseudo-XML of the file layout:

<Report>
  <row>
    <goodNumberUOM />
    <goodName />
   </row>
</Report>

In this example, the database categorizes goods by a category code (A-Z). The type of good determines the unit of measure.  In this imaginary scenario, maybe all but 5 categories have unit of measure assignments.  Everything else has the unit of measure of furlongs.  If we were converting the values using code (ABAP, perhaps?), we could implement the logic using a case statement:

  CASE L_CATEGORY.
    WHEN 'D'.
      L_UOM = 'pounds'.
    WHEN 'C'.
      L_OUM = 'ounce'.
    WHEN 'B'.
      L_OUM = 'kilogram'.
    WHEN 'Y'.
      L_OUM = 'Units'.
    WHEN 'Q'.
      L_OUM = 'SQFT'.
    WHEN 'J'.
      L_OUM = 'Other unit of measure'.
    WHEN 'G'.
      L_OUM = 'Quarks'.
    WHEN 'F'.
      L_OUM = 'Kilograms'.
    WHEN 'E'.
      L_OUM = 'Units'.
    WHEN OTHERS.
      L_UOM = 'Furlongs'.
  ENDCASE.

But how would we accomplish the same using an SAP PI message mapping? Well, one option would be to implement the logic with nesting IF blocks, but that has the nasty side effect of producing the messy message mapping shown above.  Another option is to implement the case statement in a UDF.  But a simpler option exists.  Use a FixValues mapping block.

Here is the same mapping logic using a FixValues mapping block:

And here are the FixValues settings:

Another favorite trick of mine is to use FixValues to evaluate TRUE and FALSE. This can be useful on filtering at the root level (e.g. a requirement to not send a record when the good is a type not relevant to the report you are generating).  In this example mapping, the row will not get generated if the type isn’t a D, A, T, X, S, R, E, or M:

And here are the FixValues settings:

The FixValues mapping block is a very useful message mapping block that can be used to streamline complicated SAP PI message mappings.

A Short Selective Retrospective on Key Constituencies

All project events and project success stem from testing and testing well.  I’ve written about various types of testing before and how that can lead to some confusion because of issues with definitions.  Here I want to discuss some areas where testing really can make or break a project and ideas for how to minimize the chances of things turning out badly.

SAP Testing with Project Team Members

Unsung heroes abound on SAP projects and your client’s key business analysts can be fabulous participants or sacks of rocks you have to carry everywhere for no apparent benefit.  Always choose the former or trade up if you discover you got the latter. Engaged business analysts are great when they bring business knowledge, a willingness to learn SAP, insight to the hot-button, day-to-day issues and the understanding that the consulting team may know a lot, but not necessarily everything.  Partnership between consultants and business analysts can be very fruitful at teasing out mainstream, what happens 90% of the time, business scenarios and building coherent test cases.

These key project team members can provide a sanity check when you try to bring prior experiences and findings from other clients to the project.  A crazy design you built on the last project may not be relevant here and your BA can save you from any tendency to over engineer a solution.  Conversely, your BA might be the one who sets you down the path to an unusual design.  Either way, it has to be tested and between you and the BA the bases should be covered.

I’ve found that the BA’s on a project are usually there for one of two reasons: either a motivated high performer with knowledge and credibility; or someone found the SAP project was a place to dump a personnel problem.  Fortunately, the latter is rare these days as more and more people turn into high performers out of necessity.  Consequently, your BA is going to know key areas of process and functionality that must work for the project to be a success and he/she drives you to deliver.  Never be afraid to let a BA talk about the business, what it needs to be able to do and what needs to be tested.

However, the BA probably isn’t going to be using the system as an end user on a day-to-day basis and can only get you so far with the completeness of testing.  This is where you need to branch out from the immediate project team and into the realm of the end user.

SAP Testing with End Users

In an ideal world, the systems we build would be foolproof, but there are some smart fools out there and they don’t always behave the way we want them to.  As you probably know, SAP is not the most intuitive system to navigate and use (would an overhaul of the GUI make system adoption quicker and easier?) and people don’t always do what they are told.  I know you are shocked to hear this!

If I had a lot more time on my hands I’d love to watch people using systems and seeing all the various ways people try to do things.  It’s a fairly dopey example, but I’m one of those mouse-and-menu people when I use MS Office.  The ALT, CTL, and SHIFT keys are a tiny part of my repertoire because I learned how to use these products a certain way, but I know some people who do almost everything with keyboard shortcuts.  I can scarcely follow how they do things, although I can see what they are doing.  The fun is seeing different ways to achieve the same end.  SAP is a bit like this in that there are different ways to approach a task: using menu paths; transaction codes; single session; multiple sessions; favorites list entries; and different entry points to get to data.  Unless you have really nailed down tightly how to execute tasks users will eventually find all possible ways, but more importantly, without nailing it down users will find ways to do it wrong and not realize it.  This is a potential disaster in the making.

Despite the best intentions of project team members (business analysts, consultants, trainers, supervisors) end users will use the system in ways you did not anticipate.  After all, the way you use the system works brilliantly, so no one would think to do it any differently, would they?  Except, they do use it differently.

Including a round or two of real end user testing on the QAS system is probably going to be quite revealing.  Ideally, after a dry run conversion and before going live you want to let loose on the system and do some serious day-in-the-life and periodic processing.  And you want to back off on your desire to hand hold.  This way you can see how a user actually uses the system, the steps they take when they get into trouble, and what they try to do as corrective actions.  The intuitive and natural screen flow you came up with?  Perhaps its not as intuitive as you thought.

Here’s the point: carving out time in a project to involve end users in testing is invaluable.  Initially they will stick to the script but after a short time they will extemporize and that is when you find out if you built a robust system that guides people down the desired path or a mess that allows mistakes and the attendant downstream problems.

It is better to take the time before you go live to ensure you don’t get downstream problems than to discover the chaos in production.

SAP Testing to Make Executives Happy

A final group of people with a vested interest in SAP project success is the executives.  These are rarely the folks who execute transactions on a daily basis; at best they might run a financial statement or a flash report of some description.  Nonetheless, these people along with departmental heads need to feel confident that the system works in an abstract way: a little like the way you know the engine in your car is working although you don’t really understand how all the various components fit and work together.  You’re pretty upset when the car won’t start, or the heater blows hot and cold intermittently, or you can’t tell if you have an almost empty gas tank.  Similarly executives get upset if they can’t get information that is important to them or they are unable to complete key tasks: for example, flash reports that don’t run or give “funny” numbers, not being able to close an accounting period.

These executives can be especially challenging to a project because they have so many things to worry about that they may only truly pay attention to an SAP project during times of crisis or around go-live.  At earlier times in the project life cycle they may have deferred to the PMO and existing management structure, but at crunch time things change.  Consequently, a conscious effort to find out from them what they need in order to feel comfortable with the system is critical: discovering what they need their organizations to do is critical.  Once you know what they want you can build it into project test plans and activities and show success.

This is one constituency that might be late coming to the party but you can’t ignore them or chastise them for tardiness – they are probably paying the bill!

Key Ingredients for SAP Success: Testing, Testing & (You Guessed It) Testing

It is stating the obvious (a core competence of mine) to say that an SAP project is a complicated endeavor.  I’d say there are no easy projects, only less difficult ones and testing is one of the most difficult areas to do well.

There are groups who judge testing success in different ways and with varying degrees of thoroughness.  A corner cut here and there might be acceptable, but too many cut corners and it all unravels.  By identifying key constituencies, identifying their needs, building test plans and strategies to address those needs, and executing against them greatly increases your chances of overall success.  And, if you do it right, you ensure their involvement and make them accountable for the results.

When two software systems integrate, we also have to deal with the “dropped call” problem.  SAP NCo 3.0 offers a few different levels of  data recovery options depending on whether NCo is the client or the server.  But before any data recovery can happen, the first step is to call the other party back.  This blog post describes the general process to reconnect an NCo RfcServer to an SAP gateway host.

I have read in other blogs that SAP claims their RfcServer object will automatically reconnect if it detects a dropped connection.  While this may be true, I have not seen this automatic reconnection occur in all the testing that I have done.  So, left to my own devices, I set out to figure out the best way to reconnect an RfcServer.

The first thing I did was to map out the “dropped call” process diagram.

I know that some of you are thinking that after a call is dropped it is not necessary to hang up.  This is true.  But the connection needs to be cleaned up.  In the mobile phone analogy, the phone automatically detects the dropped call and hangs up for you.  What I found during my research is that NCo 3.0 doesn’t automatically clean up broken connections, nor does it automatically clean up failed connection attemps.

Armed with this flow chart, my new found understanding of NCo 3.0, some Diet Mountain Dew, and a bag of Skittles, I decided to tackle coding a similar solution in C# using NCo 3.0.

But first, I tweaked my flow chart:

The result was a RfcServer NCo 3.0 project that would automatically recover from connection errors.  The key concept is to call the Shutdown() method of the RfcServer object after each connection failure.  Add in an event handler for the RfcServerError Event and a timer, and the rest falls into place.

Download RfcServer Reconnection Sample NCo 3.0 Project

A full sample C# project is available for download here: SAP NCo 3.0 RFC Server Reconnection Sample

Additional SAP NCo 3.0 Information

Follow these links for more information about SAP NCo 3.0 programming:

• Webinar: SAP NCo 3.0 – Best Practice Guide for Upgrade from .NET Connector 2.
• Build an RFC Client with NCo 3.0 – A Step-By-Step Guide
• Build an RFC Server with NCo 3.0 – A Step-By-Step Guide