The SAP .Net Connector simplifies creating C# programs that can interoperate with an SAP host. The SAP .Net Connector is available from the SAP Service Marketplace. You must have access to the SAP Service Marketplace to be able to download the SAP .Net Connector. The SAP .Net Connector must be installed on your development machine before we begin.

RFC is a Remote Function Call. In this case, the SAP process is a ‘client’ that is making an RFC call to our custom ‘server’ code. Our code uses the SAP .Net Connector to register on an SAP Application Gateway.

The TLA system we have been creating exists solely to demonstrate certain programming techniques involving the SAP .Net Connector and C#.  We will cover three separate parts of the solution: defining the function to SAP, creating a proxy object used to access SAP, and creating our C# code to perform the RFC function.

Defining the Function in SAP

Before we build our RFC server, we will define our RFC function in the SAP system. There are two parts we will need to create:  the Function Signature, and the RFC Destination.

Defining the RFC Function Signature

Open the SAP SE37 Function Builder screen. For the Function Module field, enter Z_RFC_TLA_HELLO_WORLD and click Create. For the Function group, press the browse button to the right of the field, then select an appropriate function Group. Enter a short text description and click Save to save the function signature.

On the Attributes tab, be sure to select the Remote-enabled module radio button.

Now we will be asked to define the parameters that are used. SAP refers to values passed to the RFC call as Import values. Values that are returned from the RFC call are called Export values.

In the Function Builder screen, on the Import tab, define a Parameter named Name. Fill in the appropriate Type and Associated Type values. Be sure to check the Pass Value check box.

On the Export tab, create a Parameter named Hello_World. This will end up storing the result of the RFC call. Define the field in the same way as the Name import field.

Save your RFC Function. Then you need to activate your RFC function. To do that, from the SE37 screen, enter the function module name. then click the Activate button.

Defining the RFC Destination

SAP can direct an RFC call to different destinations. We will create an RFC Destination using SAP function SM59. This RFC Destination is used by the SAP system to route an RFC call to our program, which previously registered itself on the SAP Application Gateway.

In the SM59 screen, click the Create button.  Enter RFC destination of TLARFCSERVER. The Connection type is T for TCP/IP. Enter a description.

On the Technical settings tab, select Activation Type of Registered Server Program.

For the Registered Server Program Program ID, enter TlaRfcSrv. The Program ID we use here must match the Program ID used when our server code connects to the SAP Application Gateway.

If you try the Test connection button, it will fail, since we have not yet registered our program on the Application Gateway. Later, we can come back to SM59 and test this and see that our RFC destination is available.

C# Code

We will create an application that can be called from an SAP host. The SAP host will pass in a name, as a string. Our application will return a hello greeting back to the calling program.

Our solution will consist of two parts.

1. The first part is the SAP .Net Connector Proxy project, named TlaRfcServerSapProxy. This will produce a Dynamic Link Library that encapsulates what we need to know to interoperate with the SAP host.
2. The second part is is our custom code project, named TlaRfcServer. This contains the code which will execute when called from the SAP host via RFC. Save the RFC destination.

Creating the SAP Proxy Project

We will use Visual Studio 2003 to create a DLL that manages the interactions with the SAP host. The SAP .Net Connector version 2.0 works with Visual Studio 2003 or 2005. To use the .Net Connector in our preferred environment of Visual Studio 2008, we will create the proxy DLL in 2003 and add that to our 2008 project. The techniques are described in our earlier post, Using the SAP .Net Connector in Visual Studio 2008.

In Visual Studio 2003, start a new Class Library project named TlaRfcServerSapProxy. Delete the default Class1.cs file that is created automatically.

From the Solution Explorer, Right-click on References and choose Add New References. Under the .Net tab, highlight SAP.Connector.dll and SAP.Connector.RFC. Click the Select button, then OK to add the SAP .Net Connector references.

Now add the SAP Connector Proxy to our project. Right click on the project and choose Add / Add New Item. Under the templates, highlight SAP Connector Proxy. In the Name field, give our proxy the name TlaRfcServerSapProxy.sapwsdl. The name we use here will become the object type name for our SAP Server Proxy object we use when we build our RFC server code.

The TlaRfcSerfverSapProxy.sapwsdl file will be displayed in Design mode. Right click on the Design surface and choose properties. This displays properties of our SAP Connector Proxy. Change the Proxy Type to Server.

Now we need to add in a reference to our SAP host so that we can pull in the signature and object model for our RFC function. Open the Server Explorer windows and expand SAP / Application Servers. Right-click on Application Servers and choose add New Server. Enter in the connection information for your SAP host. Click OK.

Expand the newly added SAP Server and right-click on Functions. Choose Add New Function Filter. In the Name Filter field, enter *HELLO* . The * is used as a wild card. Click OK to display our Z_TLA_RFC_HELLO_WORLD function in the Server Explorer.

Highlight the Z_TLA_RFC_HELLO_WORLD function in the Server Explorer, and drag it onto the TlaRfcServerSapProxy.sapwsdl design surface. This will add the necessary function signatures and object type definitions to the project.

Now attempt to build the project. It will fail, as we have not yet created the code to implement our remote function. But, when we ran the build, the SAP Connector generated an implementation stub for our server method. A new class was automatically added to our project, named TlaRfcServerSapProxyImpl.cs.

However, we desire to implement our RFC server using Visual Studio 2008.

So, we will modify this code so it will build, and later we will override the implementation from our Visual Studio 2008 project.

If you double-click on the build error, it will take you to the offending line of code. All we need to do is set the result of Hello_World to some value.  To prevent confusion with our Visual Studio 2008 code, we will just return foo.

Now build the TlaRfcSapServerProxy project and it will create TlaRfcServerSapProxy.dll, which we will use in our Visual Studio 2008 project.

Creating the RFC Server Project

Using Visual Studio 2008, create a C# console project named TlaRfcServer. In the Solution Explorer, right-click on References and choose Add New Reference. Using the Browse tab, select both SAP.Connector.dll and Sap.Connector.Rfc.dll, typically found in C:\Program Files\SAP\SAP .Net Connector 2.0.

Add a reference to the TlaRfcServerSapProxy.dll created earlier, also using the Browse tab. Add a reference to System.Web.Services using the .Net tab.

In our C# code, we need to provide the code to implement our RFC function, which we do by inheriting from TlaRfcServerSapProxyImpl and overriding the Hello World function.

On Line 3, with have our ‘using’ directive to include our custom proxy.

On line 8, we are creating a new class named SAPProxy, which is derived from our TlaRfcServerSapProxyImpl class that was created in our Visual Studio 2003 class.

On line 12 is the override of the Z_Tla_Rfc_Hello_World call. We provide our functionality and place the result in the Hello_World variable.

That concludes our class that will implement the RFC functionality.

Now we will finish off our console program so that we can establish our code on the SAP Application Gateway and execute it.

To do this,we will pass in command line arguments to our Main routine. These arguments are passed to the SAPProxy constructor, which uses them to connect to the correct SAP Application Gateway.

Each of our SAP Proxy objects are hosted by an SAPServerHost object, which is part of the SAP .Net Connector. The SAPServerHost object governs the connection to the SAP host.

Once we create the SAPProxy object and attach it to an SAPServerHost, we can start the host and that will cause our program to register and be available on the SAP Application Gateway.

Our program will continue to be available on the SAP Application Gateway as long as we have it running (until we press the enter key, in our example).

On lines 22-25, we instantiate our proxy and SAP host. Notice how we pass in the command line arguments to the SAPProxy constructor (line 25).

We start the proxy on line 29. After we have done that, we can go back to the SAP SM59 function and test our RFC destination. If things are working, that test will success.

Our code will continue to be available until we press enter at line 37, after which we stop the SAP host.

Command Line Arguments

The command line arguments consist of three parts, and are specified in the Visual Studio environment under the Debug tab of the Project Properties display.

The three parts are

-aProgram ID

-XPort

-GHost

The Program ID specified here must match the Program ID we used when creating the SAP RFC Destination. In our case this is specified as –aTlaRfcSrv.

The Port field tells SAP what TCP/IP port to use. This is specified by –XSAPGW00. The SAPGW part specifies port 3300, we add whatever the 00 is to get the actual port number. In our case we are using port number 3300, so we use –XSAPGW00. If we wanted port 3302, we would have used –XSAPGW02.

The Host field is the DNS name or IP address of the SAP server.

So, your parameters will be different but they will look something like –aTlaRfcSrv –XSAPGW00 –Ghostname

Now build and run TlaRfcServer. A console window will appear.

Go back to SAP and bring up the SM59 screen. Expand the TCP/IP connections and find TLARFCSERVER. Double click that to display the definition. When you click the Test Connection button, you should see something like :

which indicates a successful test of the RFC destination.

Now we need to test our actual RFC function. Bring up the SAP SE37 screen. In the Function Module name, enter Z_TLA_RFC_HELLO_WORLD, which matches the name of the function signature we created earlier.

Press the F8 key to test the function. The Test Function Module screen is displayed.

For the RFC Target sys, we use the RFC Function destination we created earlier, TLARFCSERVER.

For the name field, type WORLD. Press F8 to execute the RFC call.

This indicates a good test of our RFC function.

Troubleshooting

If things don’t work, check the following:

Program ID in RFC Destination matches –a parameter of TlaRfcServer command line.

Port number (SAPGW00) on TlaRfcSever comand line is set to correct port number.

Any firewalls in between the SAP host and the RFC Server program need to allow traffic in both directions over that port.

Summary

In this blog posting we have shown how you can call custom C# code from an SAP process.

At one of my clients they had a requirement to run a batch job every 5 minutes.  Sometimes the batch job would take longer than 5 minutes to complete.  Thus, the same program would start in a new batch job before the previous batch job had time to finish.  The same program would collide with itself and cause issues.

It seems that SAP’s built-in job scheduler does not have a standard way of preventing overlapping job executions.  I was hoping to find a checkbox that would deny an execution of a job if it finds the same active job running, but that would be too easy.  However, SAP does have some different options in its toolbelt to satisfy this requirement.  The approach that I will demonstrate will use an event-driven approach to execute a SAP batch job.

First I will detail the High level overview of what needs to happen.  Then, after you understand the big picture, then I will go into more detail about how to code and configure this scenario.

High level Overview

Basically 2 SAP batch jobs are needed:

1) SAP Job #1

• This job will execute every 5min or so depending on your requirment and execute a simple custom program that will check the status of Job #2.
  • If the status of job Job #2 is not running, then the custom program will raise an event
  • If the status of Job #2 is running, then the custom program will do nothing

2) SAP Job #2

• This job is setup to start only when an event is raised
  • If an event is Raised from Job #1 then Job #2 will start.  Job #2 will contain the actual programs that you need to execute.

Sound easy enough?

Step-By-Step Instructions

Now let’s get to business and see what configuration and coding we need to do.

1)      First let’s define an Event.

Transaction SM64 – I defined my event as Z_JOB_START_XXXXX

2)     Next,  Create simple Custom program ZJOB_CREATE_EVENT to Raise the Event.   This program will basically check if the specified job is currently running.  If it is not running then Raise an event which was created in the previous step above.   In my case, I will  raise event ‘Z_JOB_START_XXXXX’.   Create a variant here with the Event Name(Z_JOB_START_XXXXX) and the Job #2 name (ZJOB_XXXXX).

3)      For Job #1.  Basically set this job as Periodic Time driven job to run every 5 minutes or so with the custom program ZJOB_CREATE_EVENT.  Also make sure you include the variant with the Job #2 name and Event.

4)      For Job #2.  Define this job as an Event Driven batch job and define the actual program (I used test program ZSPTEST) that needs to be executed.  Specify the event Z_JOB_START_XXXXX that this job will be waiting for.  Also checkbox ‘Periodic job’ to schedule another event job.

That’s it…Now the batch job will only execute if the same batch job is not running.

Testing

For testing purposes, I will demonstrate by manually execute program ZJOB_CREATE_EVENT to show that how this all works.

The event ZJOB_START_XXXXX has been raised by program ZJOB_CREATE_EVENT.  Now you can see the ZJOB_XXXXX is Active/Running

During the time the job is active, I attempted to execute program ZJOB_CREATE_EVENT again.   This time, the program knows that the job is still active and, therefore, it does not raise the event.  The only time the event will be raised again is once the job is finished .

This is only one scenario in where an event driven batch job is needed.  Now you can see how you can utilize an event driven batch job to put some control around how some programs are executed.

Please note that I was unable to find the wizard for setting it the Services registry in PI 7.1 EPH1, which means I did it manually.

Make sure everything is correct in the Services Registry Management

Go to the NWA (http://host:port/nwa).

Go to SOA Management> Technical Configuration>Services Registry Management. In theory, there is nothing to do here, however I did specify the discovery URL api parameter as the hostname of the server (no port). If you have changed some settings, on the maintenance tab you can click reinitialize, which should reset any changes you have made back to the initial state.

Configure the ServicesRegistrySiPort

Go to SOA Management> Application and Scenario Communication> Single Service Administration

Click the Consumer Proxies tab.

Search for “ServicesRegistrySi”.

Click on the result and click the Configuration Tab and click on ServicesRegistrySiPort.

The service endpoint name should be ServicesRegistrySiPort.  Don’t change it.

Click security.

You have to give it an http authentication. If you don’t give the authentication, you will eventually have problems like not being able to publish to the SR, even though you may be able to access the registry.

Click on the user ID/ password, click details, and input your http authentication parameters.

Configure the third party UDDI (Only if not using SAP’s UDDI)

If you are using a non-sap UDDI, you will need to go to NWA>Destination Template Management and create a UDDI_DESTINATION and a CLASSIFICATION_DESTINATION to point to the respective urls of your uddi. Don’t forget to click security and select User ID/Password Authentication for both destinations. Otherwise, you will get a 401 not authorized error when you try to access the services registry–similar to if you mistyped your password at ServicesRegistrySiPort.

Security

Make sure that your user has  UDDI_TierN and SERVICES_REGISTRY_READ_WRITE authorizations or you will get a 401 not authorized error.  Of course. in your system you should use a technical user instead of your userid as which I did for the purposes of this blog.

Please note, I did run into an issue where it suddenly stopped working a day everything was configured. All I can say is Gremlins. I switched the user to a technical user with the authorization listed above on the ServicesRegistrySiPort as well as on the destination templates and I haven’t had a problem since.

Start Date: April 2010

Duration: 7-8 months

Description:

DataXstream is searching for a highly qualified, experienced and deliverables focused SAP Functional Consultant with expertise in inventory management (IM) and warehouse management (IM) for a project starting in April 2010.  The position requires functional expertise with additional technical understanding and skills.  This position requires you to work with the client and the implementation team to design, configure, test and deploy an SAP-based solution.  The work will also identify and produce specifications for custom development objects.

The client expects to make informed decisions based on guidance from a proactive consultant who presents options for how to execute business processes and functions along with the pros and cons of those options.

The responsibilities of the position start after project inception and continue through go-live, user training and post go-live.  If you meet or exceed these standards and would like to be a part of a highly skilled SAP consulting team please attach your resume and your completed application form below.

Required Qualifications:

• SAP functional professional with hands-on experience with SAP ECC 6.0 WM/IM implementations
• At least 5 years implementation experience on medium to large scale SAP projects in complex, time-sensitive, global environments involving multiple countries and currencies, including US and Canada
• At least three full SAP implementation lifecycles completed
• Expertise in planning, organizing, implementing, and executing the following WM/IM functionalities:
  • SAP organizational element configuration (plant/site, company code, etc.)
  • End-to-end procure-to-pay process design, test and deployment
  • Goods movements (receipts and issues) and inter-company transfers
  • Cycle counting and physical inventory processes
  • International store-to-store transfers
  • Configuration of account determination procedures
  • Labeling requirements and processing
  • Experience with both lean WMS and full WMS functionality and recommending one over the other, including put away strategy, picking strategy, cross-docking, location strategy)
  • Import and export processing
  • Integration with sales order fulfillment processing
  • Integration with handheld devices
  • Master data creation and maintenance (especially materials/articles)
  • Experience creating and maintaining pricing procedures, including in accordance with international tax laws
  • Intercompany processing between company codes with different currencies and countries of operation
  • Experience with SAP Retail solution highly desirable
  • Project lifecycle experience: requirements gathering, blueprinting, construction, realization (including integration and regression testing), go-live and post-production support
  • Documenting use cases, requirements, activity diagrams, sequence diagrams, and data flow diagrams in a technical environment
  • Writing test plans and test cases
  • Assisting in identification, assessment, and resolution of complex problems within project scope
  • Bachelors degree in computing related field or 4 additional years relative work experience in lieu of degree
  • Excellent customer relationship skills
  • US citizens/permanent residents only

Apply For This Job

Personal Information

• First Name  *
• Last Name  *
• City  *
• State  *
• Postal Code  *

Contact Information

• Phone Number  *
• Email  *

Online Information

• Website 
• Blog 
• Linkedin Profile 

Job Information

• Date Available To Work*  
• Work Status* US CitizenGreencard HolderH1-BOther
• Travel Preference* 0%25%50%75%100%
• Willing To Relocate* YesNo
• JobType* Intern (Full-Time) Intern (Part-Time) Full-time Part-Time Contract

How Did You Hear About This Position?

•  Twitter Facebook Linkedin Craigslist DataXstream Other

  Other 

Additional Information

Submit Resume

* (Required Fields)

What a great idea!  Too bad I hate this suggestion… and it’s all SAP’s fault!!

You see, SAP transaction BD53 just does not play well with others.  My full HRMD_A solution used a custom filter object (transactions BD95 and BD59) and a custom outbound IDOC formatting function module to convert change pointers into IDOCs (transaction BD60).  The dirty little secret of transaction BD53 is that every time you save and update the IDOC reduction in transaction BD53, SAP goes and screws up a bunch of configuration  displaying a message that says “Interface changed for message type <your_message_type>:  Settings reset”

Wait! What!?!

What does that message even mean?  Well, that message is telling you in very cryptic language that SAP has gone and reset the settings in BD59 and BD60 to the SAP standard! So, every time the field reductions were updated, kiss your custom filter assignments and custom IDOC processing function goodbye!

Why couldn’t the message say:

Hey Buddy! You know all that custom configuration you did to get your interface working just so? Well, its gone and you’re going to have to redo it all in the following transactions: BD59 BD60 etc.

I guess SAP is just far too polite.

So, be very cautious when you pair IDOC reduction with custom filter assignments and custom IDOC formatting function modules and be aware that every time the IDOC reduction is updated, you will need to go back in to reconfigure transactions BD59 and BD60.

For more information, see SAP OSS Note 655321

DataXstream, an SAP Solution Partner, builds, packages, and distributes custom solutions for our clients.  We develop all of our custom add-on products in our own reserved and unique namespace /XSTREAM/.  But, we also need to reserve a separate unique namespace for each add-on product that we package and deliver using the SAP Add-on Assembly Kit.  So, we have a single development namespace /XSTREAM/ and a separate “packaging and delivery” namespace for each add-on product.  Why is that?

Software Component Name and Software Component Version

Let’s begin with the software component name.  A software component name references a set of objects that are always delivered together.  It contains all of the programs, classes, function modules, tables, message classes, BADIs, basic types, transaction codes, … etc. – all of the objects which constitute a custom add-on product.   We try to make our software component names meaningful, so if we are building a product named PRODUCTA, we will try to create its software component name also as PRODUCTA.

This product has a product lifecycle which begins with its initial major release at version 1.0.  As bugs are discovered and fixed or as small enhancements are made, minor updates are released, let’s say at version 1.1, version 1.2, etc.  And after some serious product re-engineering, the product is then distributed as major release 2.0.  So, the software component name represents all of the objects which constitute the product, and the software component version represents the context of the product within its own product lifecycle.  The complete picture is provided by the combination of the software component name and the software component version.  For example, we might refer to PRODUCTA at release 1.3, which is different from PRODUCTA at release 1.2, which is different from PRODUCTB at release 2.5.

At DataXstream, we build and distribute several add-on products, so you can imagine that each product currently exists at a different release level within its own product lifecycle.  PRODUCTA may be at release level 1.3, while PRODUCTB may be at release level 2.5, and PRODUCTC may still be under construction and not yet released.  If we fix bugs in or make minor enhancements to PRODUCTA, then we need to bump the software component version of PRODUCTA (and only PRODUCTA) from release 1.3 to 1.4.

Let me add another degree of complexity to this picture.  We build and deliver the same add-on product to different SAP environments.  For example, we have clients who are running SAP in the 4.7, the ECC 5.0 and the ECC 6.0 environments.  Since these environments are different, it is possible that the same product may exist at different releases in its lifecycle across all of these three SAP environments.

To help us manage this complexity, the actual software component version release names that we actually use are a bit more descriptive than 1.0, 1.1, 2.5, etc.   This will be explained in detail later on in the section Maintaining the Software Component Version.

Maintaining the Software Component Name and its link to a Namespace

The software component name is derived directly from a valid namespace that has already been registered on your SAP system.  It is, in fact, the namespace name without the two enclosing ‘/’ characters.  This establishes a relationship between the software component name and the namespace.  SAP checks and enforces this relationship when maintaining software component names.  We try to make our software component names meaningful, so if we are building an add-on product named PRODUCTA, we will reserve and register namespace /PRODUCTA/.   This allows us to then create the software component name PRODUCTA.

In SAP, we establish our software component name using transaction SSDC.  This is the Software Delivery Composer which is part of the SAP Add-on Assembly Kit.  From the initial screen in SSDC, the menu path is Environment -> Create/Update Add-on Software Component.

On this next screen, you enter the software component name that you wish to maintain.  The software component name must be derived from an already-registered valid namespace.  For example, if you have already registered the namespace /ABCD/, then you can create a software component that is named ABCD.  SAP checks this relationship, and issues an error message if you try to create an invalid software component name that cannot be derived from an already existing namespace.

SAP allows as many as ten characters for the software component version or release name.  This allows us to build meaningful release names, which really helps to sort things out when you are dealing with many products over several SAP environments.  Here are a few demonstrative examples of how we build our release names:

Maintaining the Software Component Version

On this screen, you enter the software component version or release name, and a description, then press the SAVE icon.

Another Piece of the Puzzle – the Package

We want each of our products to have its own unique software component, because each software component or product has its own unique set of objects and needs to exist at its own software component version within its own product lifecycle.  We need to allow all of the development objects for PRODUCTA to be at release 101_470 and all of the development objects for PRODUCTB to be at release 103_500. But, if we perform all of our development for all of our products in the /XSTREAM/ namespace, how do we assign all of the /XSTREAM/ development objects for PRODUCTA to software component PRODUCTA, and all of the /XSTREAM/ development objects for PRODUCTB to software component PRODUCTB?

The answer is in the package or development class.  When creating a package, you must specify the software component that the all of package objects will be assigned to.  The example below shows the creation of a package or development class /XSTREAM/PRODUCTA.  One of the parameters of the package is the software component.  We would assign software component PRODUCTA to this package.

So, when building the product PRODUCTA, we create many development objects (programs, classes, tables, etc.) in the /XSTREAM/ namespace, we assign those objects to the /XSTREAM/PRODUCTA package, which in turn, assigns those objects to the software component PRODUCTA which exists at a particular release level in its lifecycle.

Summary

To summarize, because of the dependencies between namespaces, software components, packages, and development objects, these actions must occur in the following order:

The reduction at segment level (see also Note 301223) was facilitated in order to be able to copy message type HRMD_A. This involved setting the reduction at field level, which was not taken into account in the code because it is not possible to centrally determine which fields are mandatory and which are dependent for all country versions. In addition, for one info type there may several records for different periods of time, which may also cause a problem when you are reducing fields.

So, in essence, field-level reduction isn’t supported for HRMD_A.  The solution supplied in the OSS note suggests creating user-exit code to filter out the unwanted fields.  I already have implemented BADI HRALE00OUTBOUND_IDOC to add some other processing logic (if you’re lucky I’ll cover that logic in this blog, too), so I have a module in which I can place the code. And while the code to loop through an IDOC and clear out all instances of E1P0002-PERID, E1P0002-GBDAT, and E1P0002-GESCH is very easy, I can’t help but think I can make the code more useful.  You see, I hate unitasking code.  I can see it now.  If I take the shortcut path and wrote the unitasking code to clear those 3 fields, the code won’t be in production for more than a month before the requirements change and now there is another field that needs to be filtered out as well.  With unitasking code, I would have to crack open the code, create a transport, unit test, transport to Q, integration test, wait for a transport window, blah, blah, blah.  Ugh!  What a waste of time for a minor change.  We can do better.

I decided to create a multi-tasking module that will work for HRMD_A message types.  The fields to be cleared will be stored in TVARV in the format <SEGMENT>-<FIELD> (e.g. E1P0002-PERID).  That way, whenever the HR functional team wanted to filter out a new field, all they had to do was to update a TVARV variable.

To implement the solution, I created a new method called CLEAR_IDOC_FIELDS in my class implementation for BADI HRALE00OUTBOUND_IDOC.  CLEAR_IDOC_FIELDS has the same method signature as IF_EX_HRALE00OUTBOUND_IDOC~IDOC_DATA_FOR_RECEIVER_MODIFY:

The code is pretty straight forward.  To allow multiple interfaces to coexist in method CLEAR_IDOC_FIELDS, the TVARV variable that stores the fields to clear is in the format ‘ZHR_CLR_’ concatenated with the IDOC message type.

METHOD CLEAR_IDOC_FIELDS .
*----------------------------------------------------------------------*
* Class:     ZCL_IM_HRALE00OUTBOUNDIDOC                                *
* Method:    CLEAR_IDOC_FIELDS                                         *
* Author:    Craig Stasila                                             *
*----------------------------------------------------------------------*

  TYPES: BEGIN OF TY_FILTER,
           TABNAME   TYPE DFIES-TABNAME,
           FIELDNAME TYPE DFIES-FIELDNAME,
           POSITION  TYPE DFIES-POSITION,
           OFFSET    TYPE DFIES-OFFSET,
           LENG      TYPE DFIES-LENG,
        END OF TY_FILTER.

  DATA: WA_FILTER      TYPE TY_FILTER,
        LT_FILTER      TYPE TABLE OF TY_FILTER,
        LS_TABNAME     TYPE DDOBJNAME,
        LS_SAV_TABNAME TYPE DDOBJNAME.

  DATA: LS_NAME   TYPE TVARV-NAME,
        LT_TVARVC TYPE TABLE OF TVARVC,
        WA_TVARVC TYPE TVARVC.

  DATA: LT_DFIES TYPE TABLE OF DFIES,
        WA_DFIES TYPE DFIES.

  DATA: LR_SEGNAM TYPE RANGE OF EDIDD-SEGNAM,
        WR_SEGNAM LIKE LINE OF LR_SEGNAM.

  FIELD-SYMBOLS: <FS> TYPE LINE OF EDIDD_TT.

* Fields to clear are in variable
  CONCATENATE 'ZHR_CLR_' MESTYP INTO LS_NAME.

* Get list of fields to clear from TVARV
  SELECT * FROM TVARVC
    INTO TABLE LT_TVARVC
   WHERE NAME = LS_NAME
     AND TYPE = 'S'.

  CHECK SY-SUBRC = 0.

* Build list of fields to clear
  LOOP AT LT_TVARVC INTO WA_TVARVC.
    CLEAR WA_FILTER.
    SPLIT WA_TVARVC-LOW AT '-' INTO WA_FILTER-TABNAME WA_FILTER-FIELDNAME.
    CHECK SY-SUBRC = 0.

    COLLECT WA_FILTER INTO LT_FILTER.
  ENDLOOP.

  SORT LT_FILTER BY TABNAME.
  CLASS CL_ABAP_CHAR_UTILITIES DEFINITION LOAD.

* Get field offsets
  LOOP AT LT_FILTER INTO WA_FILTER.
    LS_TABNAME = WA_FILTER-TABNAME.

    IF LS_TABNAME NE LS_SAV_TABNAME.

      CALL FUNCTION 'DDIF_NAMETAB_GET'
        EXPORTING
          TABNAME   = LS_TABNAME
        TABLES
          DFIES_TAB = LT_DFIES
        EXCEPTIONS
          NOT_FOUND = 1
          OTHERS    = 2.

      IF SY-SUBRC <> 0.
        CONTINUE.
      ENDIF.

      SORT LT_DFIES BY TABNAME FIELDNAME.

    ENDIF.

    LS_SAV_TABNAME = LS_TABNAME.

    READ TABLE LT_DFIES INTO WA_DFIES
         WITH KEY TABNAME   = WA_FILTER-TABNAME
                  FIELDNAME = WA_FILTER-FIELDNAME
         BINARY SEARCH.

    CHECK SY-SUBRC = 0.

    WA_FILTER-POSITION = WA_DFIES-POSITION.
    WA_FILTER-OFFSET   = WA_DFIES-OFFSET / CL_ABAP_CHAR_UTILITIES=>CHARSIZE.
    WA_FILTER-LENG     = WA_DFIES-LENG.

    MODIFY LT_FILTER FROM WA_FILTER.

* Build segment name range
    IF SY-SUBRC = 0.
      WR_SEGNAM-SIGN   = 'I'.
      WR_SEGNAM-OPTION = 'EQ'.
      WR_SEGNAM-LOW    = WA_FILTER-TABNAME.
      COLLECT WR_SEGNAM INTO LR_SEGNAM.
    ENDIF.
  ENDLOOP.

* Loop at IDOC to clear fields
  LOOP AT IDOC_DATA ASSIGNING <FS>.
    IF <FS>-SEGNAM IN LR_SEGNAM.
      LOOP AT LT_FILTER INTO WA_FILTER WHERE TABNAME = <FS>-SEGNAM.
        CLEAR <FS>-SDATA+WA_FILTER-OFFSET(WA_FILTER-LENG).
      ENDLOOP.
    ENDIF.
  ENDLOOP.
ENDMETHOD.

I also added the following code to IF_EX_HRALE00OUTBOUND_IDOC~IDOC_DATA_FOR_RECEIVER_MODIFY:

* Clear IDOC fields
CALL METHOD ME->CLEAR_IDOC_FIELDS
  EXPORTING
     IDOC_CONTROL = IDOC_CONTROL
     RECEIVER     = RECEIVER
     MESTYP       = IDOC_CONTROL-MESTYP
  CHANGING
     IDOC_DATA    = IDOC_DATA.

Finally, I maintained the following TVARV variable:

That’s all it takes!  Now individual field values can be easily be filtered from outbound HRMD_A IDOCs!.

UPDATE: My colleague informed me that instead of using TVARV, I should continue to use BD53 to manage the IDOC reduction and change my code to look up the field reductions in TBD24.  This would be a great idea, but my full HRMD_A solution uses custom filter objects and a custom IDOC formatting function module.  And BD53 does not play well with these customizations.

In short, if you have done a good job with your earlier implementation activities you should have a plethora of materials that can be reused.  Remember that after an upgrade your basic goal is to still be able to do what you could do on the previous release along with anything new you are introducing.  The way you execute business functions may be slightly different, but the underlying objective should be much the same.

For more on SAP Upgrades download the white papers:

SAP Upgrade Checklist

Customization Risk Analysis in an SAP Upgrade Project

SAP Project Artifacts for Upgrades

In short, don’t reinvent the proverbial wheel if you have one available to you already.

As you went through your initial SAP implementation and ongoing support work you probably generated piles of documentation and if you managed this well throughout the ongoing project lifecycle there is a good chance that you can reuse it.  In essence, the better job you have done identifying, capturing and testing the functionality used in your SAP system the easier it should be to reuse those artifacts to confirm continuity of business processes in the new release.  It sounds easy, but it is a rare project that consistently maintains and updates project documentation as functionality is introduced through point releases, production fixes, etc.

Whatever information you have is worth reviewing to see if it can be reused or at least used as a basis for building out the scope of testing for the upgrade.  In addition to the testing scope, you may have test plans, procedures and protocols that can be adapted.  Typical project artifacts for consideration include:

Functional Scope

Any SAP project starts with an initial functional scope which grows over time.  This is a great start point for defining what you need to test and circling back to find where you implemented non-standard functionality.  The standard functionality is likely to stand up to the upgrade and work straight away, whereas the non-standard stuff is where you want to pay special attention.  In this scope you want to make sure you capture any special periodic processing, e.g. daily, weekly, monthly, quarterly and annual processes to be tested

Business Process Procedure Documents

In conjunction with your functional scope, you probably have business process procedure documents that provide detailed step by step instructions on how to execute job functions.  You can use these as a tool to verify whether business process steps have changed.  In the event that the steps have changed it is clear what documentation needs to be updated.

Technical Objects Scope

Similar to the functional scope you should have a catalog of technical objects, e.g. reports, custom programs, user exits, SAP modifications (if you went down that path), etc.  This provides a list of objects to examine and evaluate as part of the upgrade.  This is a topic covered in depth in a separate blog posting.

Test Plans, Scripts, Procedures and Tracking

Now that you have a functional and technical scope defined you can also revisit any test plans you have.  Testing comes in many flavors (click here to discuss some flavors) and you probably have prior test artifacts for functional testing, end-to-end testing, security and authorizations testing, etc. which are worth a review.  On top of this any regression test scripts and automated test tools may be re-deployable in support of upgrade testing

On top of this most projects have established procedures for tracking issues, resolution steps, and progress reporting.

Testing Organization

In conjunction with your test plans you probably have documented roles and responsibilities, test team organization structure, escalation routes and sign-off procedures.  Again, reuse all that you can.

Partner Systems, Interfaces, Batch Processing, Performance Metrics and System Outputs

Very few SAP installations are islands of functionality, instead there are numerous partner systems that interface with SAP as well various outputs in both electronic and hardcopy forms.  An inventory of these items provides another checklist for testing and identifies both internal and external partner systems you need to include in your upgrade test cases.

System performance is often critical for interfaces and batch processing and any historical activity that identified and tested these elements provides a potential guide for ensuring no degradation of these things as a result of the upgrade.

SAP Upgrade Go-Live

Again the experience from other go-live events may form a good basis for building the upgrade production implementation plan.

Supplement these artifacts with additional content for new functionality and modify for anything that has changed because of the upgrade.

Get Organized for Your SAP Upgrade

By no means am I saying that everything you have built and accumulated over the lifetime of your SAP installation is going to lend itself easily to being recycled in support of your upgrade activities.  However, I am saying that you put in a lot of work to get to this point, you already have a good idea of how to test SAP, you know the quirks and nuances of your organization, so don’t feel like you need to start from scratch.  Cast a careful eye over what you have in your project inventory and see what make sense to apply and what to discard.

And if your SAP project inventory is not a robust as it could be, think about how to strengthen it ready for the next time you have go through an exercise like this.

Essential Duties and Responsibilities:

• Responsible for the installation, technical administration, tuning, and monitoring of SAP ERP (& related) software including R/3 4.7, ECC 5.0 & 6.0, BW, XI 3.0/PI 7.0 & Solution Manager. Also Oracle and Microsoft SQL Server implementations on Windows platform
• Expertise in providing primary support for SAP R/3 related systems
• Apply support packages, and add-ons
• Provide 24×7 hour support for mission critical system software, possible on call schedule
• Effectively communicate and interact with technical personnel in solving complex business and technical problems
• Ability to complete tasks within critical timelines and work well in a high-energy environment

• Prepare status reports and attend status meetings
• Research and provide directions for SAP software corrections including SAP OSS notes and SAP support packages
• Manage the SAP router configuration for SAP support
• Design and document security administration policies and procedures (SOP) for the production environment and train the Helpdesk to perform basic operations tasks on SAP
• Creation of client landscapes and client copies
• Create and maintain RFC connections

Qualifications:

• Bachelors degree in computing related field
• 3+ years Basis administration experience working in a complex SAP environment. R/3 and middleware experience preferred
• Experience supporting and working in a project development and support environment with ability to diagnose and solve problems quickly
• Thorough understanding and skill in database concepts (Oracle preferred)
• Good coding, testing, and documentation skills required
• Have an analytical mind and the ability to delve into detail, but also have an interest in broader business issues
• Exceptional communications (written and oral), change leadership and customer service skills

• Experience in managing SAP environment changes and upgrades
• Forward looking approach that anticipates overall project and engagement needs
• Demonstrated customer service skills/attitude
• Demonstrated value added expertise in special areas of SAP technology
• Demonstrated ability to author technical specifications, presentations, and other documentation

Additional Requirements:

• 100% travel to client sites may be required
• US citizens/permanent residents only

Start Date: April 2010

Duration: 7-8 months

Description:

DataXstream is searching for a highly qualified, experienced and deliverables focused SAP Functional Consultant with expertise in SD for an upcoming project in April 2010.  The position requires functional expertise with additional technical understanding and skills.  This position requires you to work with the client and the implementation team to design, configure, test and deploy an SAP based solution.  The work will also identify and produce specifications for custom development objects.

The client expects to make informed decisions based on guidance from a proactive consultant who presents options for how to execute business processes and functions along with the pros and cons of those options.

The responsibilities of the position start at project inception and continue through go-live, user training and post go-live.  If you meet or exceed these standards and would like to be a part of a highly skilled SAP consulting team please attach your resume and your completed application form below.

Required Qualifications:

• SAP functional professional with hands on experience with SAP ECC 6.0 SD implementations
• At least 5 years SD configuration experience on medium to large scale SAP ECC projects in complex, time-sensitive, global environments involving multiple countries and currencies, including US and Canada
• At least three full SAP implementation lifecycles completed
• Expertise in planning, organizing, implementing, and executing the following SD functionalities:
  • SAP organizational element configuration (sales organization, company code, etc.)
  • Sales order fulfillment processing, including but not limited to: quotes, customer orders, intercompany orders, transfer orders (store-to-store, site -to-site), samples, returns
  • Sales tracking by associate and commissions processing
  • Available to promise processing
  • Integration with logistics processing, e.g. delivery processing
  • Invoicing processing and integration with FI
  • Payment card processing (credit and debit cards)
  • Master data creation and maintenance (customers and materials/articles)
  • Configuration of account determination procedures
  • Creation and maintenance of access sequences
  • Retail pricing procedure maintenance
  • Output determination
  • Intercompany processing between company codes with different currencies and countries of operation
  • US and Canadian tax processing
  • Experience with SAP Retail solution highly desirable
  • Project lifecycle experience: requirements gathering, blueprinting, construction, realization (including testing), go-live and post-production support
  • Documenting Use Cases, Requirements, Activity Diagrams, Sequence Diagrams, and Data Flow Diagrams in a technical environment
  • Writing test plans and test cases
  • Assisting in identification, assessment, and resolution of complex problems within project scope
  • Bachelors degree in computing related field or 4 additional years relative work experience in lieu of degree
  • Excellent customer relationship skills
  • US citizens/permanent residents only