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.

Let’s look at how this process works.  Let’s say we have created an invoice document in SAP.  In this case, the Sold-to, Ship-to, and Bill-to partners are all SAP customer number 15.  If we want to create an INVOIC02 IDOC on which the external customer numbers are populated for all three of these partners we would have to set up three EDPAR entries as displayed on the below screen shot.  The Customer field will contain the SAP partner number (Sold-to, Ship-to, Bill-to).  The Ext. Function field will contain the Partner Function (SP = Sold-to, SH = Ship-to, BP = Bill-to).  The External Partner field will contain the external partner number that the customer is expecting on the EDI file.  And the Int. no. field will contain the SAP partner number (Same as the Customer field).

After we have set up the Partner Profile (WE20) for the INVOIC for this customer we can produce the output through transaction VF02 to create the IDOC.  The INVOIC02 IDOC will display the Sold-to and the Bill-to partners at the Header level in the E1EDKA1 segments, but because we could have multiple Ship-tos on an invoice the Ship-to partner(s) are located at the Item level in the E1EDPA1 segments.  In both segments, the external partner numbers will be populated in the LIFNR element.  The segments for the three partners are displayed below:

As you have probably noticed, the Partner Functions on the IDOCs do not match the Partner Functions in the EDPAR table.  Those would translate as follows: SP in EDPAR = AG in the IDOC, SH = WE, BP = RE.  As you can see the LIFNR field is populated with the values in the External Partner field of the EDPAR table.  These values can now be used in the EDI mapping tool to send the value to the customer.

This is a useful tool as new partners can be added easily using the VOE4 table by a customer service representative.  It also keeps the cross reference within SAP so that the EDI group does not have to build their own functionality to convert the partner numbers and maintain it as new customers are added or locations are changed.

This table can be used for other partner types and other outbound IDOCs.  You would need to check the function module that processes the output to see if it uses the EDPAR table and for which partners.  Another internal SAP table that is used for partner cross reference is the PUMA table.  This is used when creating DELVRY and SHPMNT IDOCs whose function modules do not use the EDPAR utility.  The use of the PUMA table will be discussed in a separate blog.

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.

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

SAP .NET Connector 2.0 offered a couple of different sample projects that were instrumental in my learning process.  As I mentioned in my post detailing the steps to build an RFC client, SAP no longer supplies code samples with SAP .NET Connector (NCo) 3.0.  So, I decided to make available some code examples created by my colleague, Terry DeBruicker.

This blog describes how to build a simple RFC Server using the SAP NCo 3.0. The sample program implements RFC STFC_CONNECTION.  STFC_CONNECTION is a good example to use because it contains both importing and exporting parameters.

Click here to request a .zip file containing a copy of the source code.

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 console project. In the project properties, be sure to set the Target Framework to .Net Framework 4.0.

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

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 simple example, we are using an app.config file to define our SAP host connection information.

One of the biggest differences between NCo 3.0 and NCo 2.0 is how function metadata is retrieved and stored.  With NCo 2.0 the function metadata was downloaded from an SAP system at design  time and persisted as proxy objects that were compiled with the rest of your solution.  NCo 3.0 needs to access this metadata at runtime.  There are two methods for providing this metadata.  One method is to create the metadata in your .NET code.  The other method is to rely on the metadata stored in the SAP system.  For this example, we will rely on the SAP system to provide RFC metadata.  This metadata is retrieved using special built-in RFCs.  Therefore, not only will our program act as an RFC server, it will also need to act as an RFC client.

For basic RFC server configuration, there are two configuration sections that are used, <ClientSettings> and <ServerSettings>.  Ensure that the app.config file has a <sectionGroup> tag for both client and server settings.

An RFC server configuration is linked to a RFC repository by use of the REPOSITORY_DESTINATION attribute.  To be able to access function metadata, this attribute must match the name of a destination configuration in the client settings section.

All SAP NCo 3.0 RFC servers communicate with SAP through a SAP service called the gateway.  The server settings configuration section  defines how the program connects to the SAP gateway.  In the servers section, the NAME field identifies this app.config entry to our  program. The SAP .Net Connector 3.0 will use the values in the GWHOST, GWSERV, and PROGRAM_ID fields to register our program on the SAP Application Gateway. The PROGRAM_ID specified here must match the Registered Server Program ID specified in the RFC destination.

The SAP RFC Function Interface

SAP transaction SE37 can be used to determine the parameters for the STFC_CONNECTION function. This describes what parameters will be passed to our function, and what results are expected.

In this example, we expect to receive parameter REQUTEXT, which will be returned to the caller in ECHOTEXT. We also return a text string to the caller in field RESPTEXT.

SAP transactoin SM59 is used to configure the SAP RFC Destination. In this example, the name of the RFC Destination (NIMBUS) is the name of the development computer that is running the RFC Server. The registered program ID (NCO3_RFC_SERVER) matches our app.config file.

The Code

As an Nco developer, one of my favorite changes brought about by Nco 3.0 is how RFC server functionality is implemented. Instead of overriding generated stub method, we need to implement one or more class methods that will process the incoming RFC calls. For this there are several possibilities:

• The first option is to create one static method corresponding to each SAP function module to be implemented.  Assigning a SAP function module to a method is done by decorating the method with the RfcServerFunction attribute.
• The second method is to create one static method for that handles all SAP function modules. This is called the “default” method. Use the same RfcServerFunction method decoration as the previous option, but denote that the method is the defualt RFC handler. The Name attribute is irrelevant in this case.  These two methods for RFC Function handling can be combined in the same project.

It is also possible to use either of the two previous options with instance methods instead of static methods.  For the purposes of this example, we will use a static method to implement our RFC Server.

We will create a class that exposes a method that can be called via SAP RFC.  In our example that class is named DxsRfcServer and it contains one method that will supply the STFC_CONNECTION functionality.  Now perform the following steps to implement class.

1. Provide the RFC callable code. This is done in our DxsRfcServer class, where we have a method defined. The RfcServerFunction code attribute on line 59 identifies this function to the SAP .Net Connector as the method that implements SAP function STFC_CONNECTION. On line 60 is where we are passed two parameters that contain all of the information we need to execute our function. The IRfcFunction interface provides access to parameter values. In this case we use the .GetString() method on line 69 to extract the value of the REQUTEXT parameter. We also can return values to the RFC caller using the IRfcFunction interface by using the .SetValue() method as seen in lines 69-70.
   
2.  Create an array of types, with just one element that refers to our DxsRfcServer class.
   
3. Register the array with an RfcServer object.  Notice that on line 22, the first parameter to the .GetServer() method is the NAME field of the servers section in app.config.
   
4. Start the RFC server.
   
5. At this time, the SAP system has visibility of our program running on the application gateway. (SAP transaction SMGW Goto menu->Logged On Clients)
   
6. Use the test function screen in transaction SE37 to test the new function. The RFC Target System is set to the name of the RFC destination created in the previous step (in this case it is our development system name).
   
   Here are the results:
   
7. The command console will also display some useful information:
   

The rest of the code is regular Windows Console programming and is very straight forward.

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 Server with NCo 3.0