Build an SAP RFC Server using the SAP .Net Connector
This blog post describes step-by-step how to use the SAP .Net Connector and Microsoft C# to create an SAP RFC Server. This allows an SAP process to call your custom C# code, which can accept parameters and return values.
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.
Read more
Troubleshooting the Services Registry
Recently I set up the services registry for PI 7.1 EHP1 for a client of ours. Although it seemed like it would be a simple process, I ran into a 401 authorization issue and another issue where web services were not publishing to the services registry. Looking online there are a lot of people who ran into the same issues as I did, so I am providing, here, the steps to perform if your services registry isn’t working.
BD53 Doesn’t Play Well With Others
I recently posted a blog about how to implement field-level IDOC reduction for the HRMD_A message type. In short, the standard SAP transaction to reduce IDOC segments and fields (transaction BD53) can’t be used because the field-level reduction is ignored by SAP. My solution leveraged TVARV as a repository for the fields to clear. Read the whole solution here. A colleague of mine was very quick to point out that instead of using TVARV as the method for controlling which fields are cleared, I should have continued to leverage transaction BD53 for the IDOC reduction maintenance and changed my code to look up field level reductions in table TBD24.
What a great idea! Too bad I hate this suggestion… and it’s all SAP’s fault!!
How To Implement Field-Level HRMD_A Reduction
I love ALE. It is super-powerful and, once you get the hang of it, is a snap to configure. Recently, I was setting up an HRMD_A interface for my client. Everything was going smoothly until I ran into a requirement to filter out the social security number (PERID), birthdate (GBDAT), and gender (GESCH) for privacy reasons. All of these fields are in segment E1P0002. Initially, I thought that this requirement was easy enough to accomplish. I just created a IDOC reduction in transaction BD53 and filtered out the three fields. I soon found out that while entire segments were getting reduced from the IDOC as configured, the individually reduced fields were still showing up in the IDOC. What’s going on?!? Read more
Build an SAP IDOC Receiver Using the SAP .Net Connector
Overview
This blog post describes how to receive an IDOC from an SAP system, using the SAP .Net Connector and Microsoft C#.
Introduction
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.
An IDOC is an Interface Document that is used to send or receive information to or from an SAP host. An IDOC will consist of a header record and as many detail records as necessary. The header records follow the format of the EDI_DC40 table, and the detail records follow the format of the EDI_DD40 table. The exact format of the payload in the detail records depends on the type of IDOC being transmitted.
Read more
How To Debug ABAP Web Service on SAP Web Application Server (WAS)
One of the more confounding aspects of developing in the SAP space is the lack of good, low-level, helpful instructions. While this post is merely regurgitating information that is readily available elsewhere, it will be done in a manner that (hopefully) will actually be useful to vast majority of ABAP developers out there that, like me, find a lot of SAP’s implementation of web services on the ABAP stack confusing.
Debugging a web service on the ABAP stack of SAP Web Application Server is a very useful procedure to know. Here’s how you do it.
Changing The Function Interface of Web Service Enabled Functions
Today, I got an email from one of my co-workers at my client with a very good question. This developer had created an ABAP function to return SAP data. Then, he exposed this function as a web service. Due to changes in functional scope, he had to change the function interface. After he made all his changes and unit tested the ABAP code, he was surprised to find that his web service was still adhering to the old function interface. He tried deleting and recreating the web service, but ran in to problems. He was stuck in a pickle and needed a little push in the right direction.
Discovering Something Old in SAP – Using an External Program as a Batch Job Step
Occasionally, I have the opportunity to utilize a feature in SAP that I have never used before. It is not necessarily a new feature, and it may have existed in SAP for several releases. There are several reasons for ignoring new functionality, but the primary reason that comes to mind is “I’ve always done it this way, I’ve installed hundreds of these, and I know it works”.
Sometimes, a special business or security requirement does not permit the “business as usual” scenario. It is these situations which nudge me down the path which I have never explored.
SAP Standard Sale Area Cross Reference For Inbound IDOC Processing
Cross Reference To SAP Sales Area From External Customer Number – SAP EDSDC Table
If you have ever converted an external file into a SAP Sales Document IDOC (ex: ORDERS05) you may have hard coded the E1EDK14 segments of the IDOC which specify Sales Area and order type for the SAP Sales Document. However, these segments are not required if you populate the E1EDKA1-LIFNR segment of the IDOC with the External Customer Number and populate the EDSDC table with the Sales Area and Order Type for the customer. Your SAP system contains a standard utility that converts the External Customer Number to the Sales Area values and Order Type value contained in this table.
Sales Area Cross Reference From IDOCs ORDERS05 and DELFOR02
This utility is available in the standard SAP package to convert External Customer Number to SAP Sales Area when processing inbound IDOCs (ex: ORDERS05, DELFOR02) from non-SAP systems. It eliminates the need to add E1EDK14 segments to the IDOC as it populates the Sales Organization, Distribution Channel, Division, and Sales Document Type using the entries in the EDSDC table which is populated using transaction VOE2. In order for this process to work, you must have the Customers External number populated in the E1EDKA1-LIFNR field of the IDOC where E1EDKA1-PARVW is ‘AG’ and the EDPAR Customer Conversion table set up to convert the Customer External number to the SAP Customer number. See my blog ‘SAP EDPAR Table – External Customer Number cross reference to SAP Customer Number’ for instructions on the External Customer Conversion. By properly doing this, the standard SAP function module will use the EDSDC table to convert the External Customer Number to the SAP Sales Area and Document Type. The following instructions will explain how to populate the inbound IDOC and the EDSDC table.
SAP Standard Customer Cross Reference For Inbound IDOC Processing
Converting External Customer Number To Internal Customer Number – SAP EDPAR Table
Have you ever had a project where you are converting a customer file into an SAP Sales Document IDOC (ex: ORDERS05) and the customer file contains their Internal Customer Number? So you need to determine what the SAP Customer Number will be on the IDOC. If you are not familiar with the SAP interface process you may hardcode the SAP Customer Number or create external tables in your third party mapping software to accomplish this conversion process. However, this involves customer specific logic or updating the tables with your SAP Customer Numbers and having a process to maintain this table as new SAP Customer Numbers are created. There is a much easier way to perform this conversion with no additional coding as it is a standard SAP utility.
Customer Conversion For IDOCS ORDERS05 and DELFOR02
This utility is available in the standard SAP package to convert External Customer Numbers to SAP Customer numbers (Sold-To, Ship-To, etc.) when processing inbound IDOCs (ex: ORDERS05, DELFOR02) from non-SAP systems. When working with data that will be imported into SAP via IDOC format the data usually contain your customers external sold-to and ship-to numbers and not the associated SAP customer numbers. Therefore, you would need to convert this External Customer Number to your internal SAP Customer Number. Instead of creating cross-reference tables or conversion routines in your third-party translation software you can populate the E1EDKA1-LIFNR field of the inbound IDOC with the External Customer Number and use transaction VOE4 to populate the EDPAR table. By properly doing this, the standard SAP function module will use the EDPAR table values to convert the External Customer Number to the SAP Customer number. The following instructions will explain how to populate the inbound IDOC and the EDPAR table.
