Coming Soon: SAP .NET Connector (NCo) 3.0
SAP is announcing a new version of SAP Connector for Microsoft .NET 3.0 (now called “NCo 3.0″). A beta program for selected customers and partners is currently underway (Q3, 2010) with the general release of the software coming soon thereafter. I will highlight some of the major differences between the SAP Connector for Microsoft .NET 2.0 and NCo 3.0 (besides the obvious, and much-needed name-shortening).
What’s in a Naming Convention? Part II
In my last post, I discussed naming the naming convention that DataXstream recommends for SAP PI Integration Directory (ID) objects. I would like to say that I had a great DataXstream ESR-specific naming convention, however the SAP naming convention guide for PI 7.1 does the job perfectly. Here is the link to the PI 7.1 naming convention guide http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/40a66d0e-fe5e-2c10-8a85-e418b59ab36a?QuickLink=index&overridelayout=true . I would like to point out some things that I feel most people miss, as well as some things that I think are particularly interesting.
Object Name Prefixes
I have seen a lot of places use prefixes or suffixes before objects such as or dt_ or _mt. I have never really been a fan of these prefixes and suffixes, and apparently neither is the above linked naming convention guide. The reason being is that they are unnecessary. It would be difficult to confuse a message type with a data type in a real interface scenario, even if troubleshooting an unknown broken object. Plus it makes message mapping unnecessarily confusing and long since it’s not clear whether to add the prefix, i.e. MT_one_to_MT_two. Good descriptive names are usually all that you need e.g. DEBMAS_to_Customer. The only possible exception to a no-suffix-or-prefix-policy is the service interface, as sometimes it is useful to know which direction and type a service interface is. An argument for a prefix or a suffix to describe a service interface would be to assist in understanding the flow from an SAP perspective in the event that someone who didn’t develop the interface had to come behind and troubleshoot. A argument against would be the fact that it looks silly if you use it for a web service, because you have a name that doesn’t mean anything to a third party user (note operation mappings are told to omit the prefix of direction and mode in the SAP guide).
One interesting thing that I noticed in my investigation of PI 7.1 EHP1 is that it appears that naming conventions on PI can be validated. If the object names do not conform to a naming convention a message will appear. Ter perform this check in the ESR go to menu Tools>Component Check.
Select “Governance” and “Interface Name Checks”:
If the service interface does not end with (In/Out)(SYNC/ASY) the interface check will show as an error (does not impact interface processing). I created 2 interfaces: one good and one bad to show this error.
My suspicion is that SAP will put more in place to force consistent naming standards depending on the service interface pattern in future releases.
Using a software component and Namespace for each “side” of an interface
All objects of an interface should not be grouped in a single namespace. They should to be split among the Software Component Versions of the systems being interfaced. Otherwise when you go to configure, you will not be able to see your operational mapping (OM) in the dropdown box without having to select all in the dropdown menu. A general rule of thumb is: if it’s not easy to configure, odds are you have probably done something wrong. Another reason why an object might not appear in the dropdown menu (for example for an operations mapping on an interface mapping) would be if the installed checkbox is not clicked on the SLD. When done correctly, most interfaces should be able to be configured quickly and intuitively in the integration directory (ID) without the need to select from all SWCV from dropdown menus on the integration builder.
Whatever naming convention you choose to use for the ESR, the important thing to remember is that adhering to the standard makes production support and troubleshooting faster and easier.
What’s in a Naming Convention?
It doesn’t take long for a PI implementation to become a complete mess if standards are not put in place before development occurs. Even among seasoned developers, opinions vary as to the best way to name and organize the IR (ESR) or ID (IB), depending on different backgrounds and previous project experience. In the next few blogs I would like to touch upon some of the best practices that we utilize in our implementations at DataXstream, which we have arrived at though our project experiences and discussion, both internally and with other middleware experts. Read more
IDoc Has Left The Building
SAP IDocs are a tried and true interface methodology. But as with any interfacing technology the most brittle component is the connection between the two systems (in the case, SAP and the subsystem). In scenarios where SAP is sending IDocs to a subsystem via the transactional RFC, one question is paramount:
How do you know when an Outbound IDoc has physically left SAP?
It’s a simple fact that if your subsystem never receives an IDoc from SAP, the subsystem will not be able to route or process the IDoc. I have always gone by the notion that once the subsystem has successfully received the IDoc, the subsystem now has all the responsibility to process and route the IDoc, but before that time, SAP has the responsibility to ensure that the IDoc is fully dispatched. The subsystem should have processes in place to determine if the IDoc has been received at the target system successfully or not. In this blog I will focus on the handshake between SAP and the subsystem. This will entail Outbound IDoc status and a couple of batch jobs that should be setup to ensure a better chance of a successful handoff between SAP and the subsystem.
Too Many Developers Spoil The Code
You may have heard the following idiom before:
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? Read more
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.
