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
SAP Event Driven Batch Job
When creating SAP batch jobs to run a program, most of the scheduling can be accomplished by setting a periodic time for when the job is executed. For example, execute the job every 10min, 30min, or 1 hour. But what if you needed more control of when a batch job was executed?
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!!
The Software Component
In my last blog entitled What’s in a Namespace, I discussed the value of developing deliverable custom solutions in a reserved unique namespace. In this blog, I will discuss how a namespace is related to a software component. I will also discuss the typical product lifecycle, the software component version, and the convention which we use for establishing the software component version release increments.
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?
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
21 Things to Remember for Your Next SAP Upgrade
Is it time for your company to consider an SAP Upgrade?
The choice to upgrade your company’s SAP platform is a very important business decision. Many criteria need to be considered when determining if an SAP upgrade is the right move and, if so, what type of upgrade needs to take place (ECC 6.0, Enhancement Packs, etc.). A successful SAP upgrade requires the determination of your upgrade requirements, proper planning, and an assessment of technical and functional risk. Below is a sample of our SAP Upgrade Checklist white paper:
Determine Your Upgrade Requirements
- What are the business reasons for upgrading? Support from the business for an upgrade project is most important. If there are no business reasons for upgrading, then you should probably not do it. Included here are the business risks incurred by not upgrading.
- What are the technical reasons for upgrading? Included here are the technical risks incurred by not upgrading. (Posture increasing maintenance fees for old versions or complete support withdrawal as a business risk – not a technical risk.)
For the complete list, download the full white paper:
SAP Upgrade Checklist
Related Links:
What’s in a Namespace?
Introduction
DataXstream, an SAP Solution Partner, builds, packages, and distributes custom solutions for our clients. We have built and packaged these solutions both in our own SAP landscape and in our client’s SAP landscape. In doing so, we must be careful about how we manage our namespaces, their associated development and repair license keys, and packages. It is not surprising, then, that I have received several inquiries asking about our namespace strategy for the development, packaging, and distribution of add-on products.
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
Command Line Driven Transporting Using the ‘tp’ Command
STMS is a very powerful transaction in the BASIS world. The whole transport system in SAP is paramount to it’s functionality. 99% of the time, you will use STMS for your transport needs. What of that last 1%? Sometimes it becomes more efficient, or just safer, to have a little more manual control.
