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

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.

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

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.

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 60)
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 62)
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 68)
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 70)
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 75-79)
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 78-84)
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 88-99)
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 101)

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

Duration: 1 hour

Speaker:  Craig Stasila, Principal, DataXstream

This one hour webinar will supply you with knowledge of features specific to the new upgrade, as well as an overview of the advantages that come with investing in NCo 3.0.

What Will Be Highlighted:

• Changes and new features brought upon by the NCo 3.0 update
• Demonstrations of best-practices for implementing new and existing NCo code
• Live demonstration of inbound and outbound function calls between a .NET solution and SAP ECC

Date:  Thursday, August 11, 2011

Time:  1:00 pm ET / 10:00 am PT

Duration: 1 hour

Speaker:  Craig Stasila, Principal, DataXstream

Register Today!

Please join us Thursday, August 11 at 1 pm ET for an overview and best practice guide for upgrading to the recently released SAP .Net Connector (NCo) 3.0.  This one hour webinar will supply you with knowledge of features specific to the new upgrade, as well as an overview of the advantages that come with investing in NCo 3.0.

What Will Be Highlighted:

• Changes and new features brought upon by the NCo 3.0 update
• Demonstrations of best-practices for implementing new and existing NCo code
• Live demonstration of inbound and outbound function calls between a .NET solution and SAP ECC

Win a Dell Streak!

We’ll be giving away a sleek Dell Streak to a random registered attendee at the end of each webinar. You must be in attendance to claim your prize.

Included in the downloads are documents that discuss the notable changes from .NET Connector 2.0 and a very comprehensive help file (in .chm format).  Noticeably absent are complete samples, although SAP claims that the included tutorial will be updated.

Additionally, I already have my first NCo 3.0 project under way, so check back soon for more information about NCo 3.0!

Happy Coding!

[UPDATED]

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
• 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

EDITOR’S NOTE: NCo 3.0 has now been released.  Read more details here.

NCo 3.0 Logon

One of the new features implemented to combat the malevolent for RFC client attacks is the interface IDestinationConfiguration. This interface contains method IDestinationConfiguration.GetParameters(string destinationName) which allows .NET programmers to provide their own secure method for storing and retrieving logon information, be it encrypted database, encrypted file, or even LDAP.  There is also a corresponding interface and method to secure NCo 3.0 RFC servers.

Additionally, there is updated functionality to support single sign-on (SSO) and X.509 certificates.

Say Goodbye to Data Containers and Generated Code

In SAP Connector 2.0, working with RFCs required the generation of proxy code via the SAP .NET Connector design-time tool.  This tool would convert the IMPORTING, EXPORTING, CHANGING, and TABLES parameters from the RFC you were calling/serving to .NET representations of the same.  With NCo 3.0 there is no longer any kind of generated code.  Instead of one generated proxy method for each function module, there is one single RfcFunction class, whose Invoke() method dynamically executes every given ABAP function module. Additionally, all ABAP parameters will be represented by the class RfcStructure instead of a dedicated generated class for every structure; All tables will be represented by class RfcTable.  So, instead of hard-coding all of the data and variable bindings statically at design time, NCo 3.0 now handles everything dynamically at runtime.

NCo 3.0 uses SAP’s data dictionary to determine the function interface for the called RFCs.  While this data is cached locally for performance reasons, NCo 3.0 is robust enough to detect changes in RFC interface signatures so your code will still execute if you’ve added, deleted, or changed RFC parameters.  If there arises a situation where the dynamic lookup of RFC interface signature is not wanted, there is also an option to hard code the RFC parameter metadata.

The biggest benefit of NCo 3.0′s new dynamic function handling is that NCo 3.0 no longer has a design-time component.  This releases the Visual Studio version restriction that .NET 2.0 had.  Let me rephrase that, NCo 3.0 will work with any version of Visual Studio you like! The only requirement is that at runtime, a .NET Framework version is installed that is compatible with the NCo 3.0 libraries.

Anxiously Waiting

NCo 3.0 figures to be a much-needed update to a vital SAP integration technology.  I, for one, cannot wait for the new functionality to be generally released.  Once NCo 3.0 is released we’ll be posting blogs highlighting the new features.  We’ll also include helpful information regarding a .NET Connector 2.0 to NCo 3.0 upgrade.  In the meantime, if you have any leave any questions or comments you have regarding NCo 3.0 below.  You may also email me directly at csta...@dataxstream.com if you’d like to set up a detailed conversation.

Too many cooks spoil the broth

The common meaning extracted from this saying is that too many people working on a single task tend to make a mess of it.  But, what happens when you have too many developers working in a single piece of ABAP code?  That’s right, you get a big mess.  This issue is especially difficult to deal with when there are multiple functional requirements leveraging the same custom code object, form-based user-exit, or function-based user-exit.

While current releases of SAP (those built on SAP NetWeaver 2004s and later) have good built-in handling of enhancements and customizations via implicit and explicit enhancement points and BADIs, there still exists many old-school user-exits.

Multiple Developers; One Code Object

I recently worked on a project where three separate developers were creating three separate interfaces based on the outbound delivery IDOC.  While the development for all three interfaces was occurring at the same time, the go-live date for each of the interfaces were different (we’ll discuss that project management glitch at another time).  Each interface required a separate set of custom fields and, therefore, it’s own IDOC extension.  The problem is there is only one appropriate user-exit in IDOC_OUTPUT_DELVRY and three developers needed to be developing in it at the same time!

How did we solve this problem?

An Object To Call One’s Own

To allow each developer his own development object and transport timeline, I decided to implement a custom multiple-use, filtered BADI inside the SAP user-exit function EXIT_SAPLV56K_002.  Actually, you can implement your own BADI almost anywhere you need alternate logic execution–even custom code!

So you might be saying, “Create my own multi-use, filtered BADI definition? Sounds complicated.” Well, it’s easier than you think!

NOTE: This solution was done on an ECC6 system based on SAP NetWeaver 2004s.  The steps to implement this type of solution in ECC5 (SAP NetWeaver 2004) are very similar.

Create A Custom BADI Definition

1. To create a new enhancement spot definition, use transaction SE18.  I named my enhancement spot Z_EXIT_SAPLV56K_002 because the enhancement spot will be used in user-exit function EXIT_SAPLV56K_002.
   
2. In the ensuing dialog box, enter a description and choose BAdi Definition for the Technology
   
3. Next, create a new BADI definition.
   
4. Specify that the new BADI definition will be multiple use and limited to filtered use.
   
   Making the BADI definition multiple use means that each developer can create his or her own BADI implementation.  Each BADI is implemented in its own class.  This promotes code separation and the proper reuse of shared development objects.
   Making the BADI definition limited to filter use ensures that the BADI implementations are separate and cannot affect every interface using the user-exit.
5. Now, create a new filter.
   
   BADI filtering in SAP NetWeaver 2004s is much more powerful than in previous versions of SAP.  Read more about BADI filtering here.
6. The BADI we are defining will be used to populate IDOC extensions.  Each IDOC extension has its own message type (e.g. ZMHL_DESADV, ZQTC_DESADV, ZMHL_SHPORD), therefore the message type of the IDOC being processed is a good value to filter on.  I named my BADI filter EDI_MESTYP.
   
   SAP allows for the automatic checking of BADI implementation filter values.  The standard domain EDI_MESTYP has a value range of table EDMSG attached to it.  This is exactly the range of values I want as allowable values, so I configure the BADI filter to automatically check the filter values against dictionary object EDI_MESTYP.
7. Next, create the BADI interface that will be inherited by each implementing class
   
8. The original user-exti function EXIT_SAPLV56K_002 is executed after each segment is added.  Our BADI will do the same.  Create a new public interface method SEGMENT_ADDED.
   
9. The BADI we are creating is replicating user-exit function EXIT_SAPLV56K_002.  Here is the function interface for EXIT_SAPLV56K_002:
   
   Here is the same data being passed via the interface method.
   
10. Lastly, the BADI has to be called from the existing user-exit.  I will not cover the steps required for implementing user-exit function EXIT_SAPLV56K_002 here, but once you have the user-exit implemented, add the following code.  This code should be the only logic directly inside the user-exit.  Any data processing logic should be implemented via a BADI implementation:

    DATA: GO_BADI TYPE REF TO Z_EXIT_SAPLV56K_002.
    DATA: L_STR TYPE STRING.
    L_STR = MESSAGE_TYPE.
    
    * Get BADI class based on IDOC message type
    GET BADI GO_BADI
       FILTERS EDI_MESTYP = L_STR.
    
    * Execute SEGMENT_ADDED BADI method
    CALL BADI GO_BADI->SEGMENT_ADDED
       EXPORTING
         MESSAGE_TYPE       = MESSAGE_TYPE
         SEGMENT_NAME       = SEGMENT_NAME
         DATA               = DATA
         TAB_IDOC_REDUCTION = TAB_IDOC_REDUCTION
         FLT_VAL            = MESSAGE_TYPE
       CHANGING
         CONTROL_RECORD_OUT = CONTROL_RECORD_OUT
         IDOC_DATA          = IDOC_DATA[].

We’re done with creating the BADI definition!  Save and activate your work. I bet you’re saying to yourself, “Wow, that was easy!”

BADI Implementation

Implementing the BADI you just created in the steps above is just like implementing any other BADI in SAP, so here are the Cliff Notes version of implementation instructions.

1. Using transaction SE19, create a new enhancement spot implementation for Z_EXIT_SAPLV56K_002.
   
2. Enter the BADI implementation details.  This particular BADI implementation is for RICEF ID MHL-IO-007, so I added that identification to the BADI implementation name and implementing class name.
   
3. In the BADI definition, we required each BADI implementation to be filtered on message type. This particular BADI implementation is for message type ZMHL_SHPORD.  Create the filter combination for the BADI implementation.
   
4. This ensures that the other interfaces using this BADI (ZMHL_DESADV, ZQTC_DESADV) will not execute the code implemented with this BADI.
   
5. The final steps are to add the code to the SEGMENT_ADDED method just like you would in user-exit function EXIT_SAPLV56K_002.  Once you are done, save and activate your changes!

Summary

As you can see, with a few extra steps, it is possible to have your cake and eat it, too, by create a custom BADI definition that can be used by other developers.  All this talk of food is making me hungry.  Is it lunchtime yet?