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!!
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?
SAP Basis Consultant
Location: US-Multiple Locations
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
DataXstream Virtualizes Lumber Liquidators’ SAP Landscape
Virtualization Project OverviewDataXstream LLC and Lumber Liquidators have announced a business relationship in which Lumber Liquidators has purchased a completely virtualized SAP platform from DataXstream built on VMware and Dell EqualLogic. Lumber Liquidators’ SAP NeedsLumber Liquidators acquired SAP to automate all their back-office processes. Prior to implementation, they were instructed to deploy a hardware platform that would support not only the initial implementation, but incremental growth for the next 3 years. As a new implementation, they were also concerned with minimizing total project cost, delivering high availability and consistent performance to an unknown number of users, and be easily maintainable by a streamlined IT staff. SAP Virtualization SolutionLumber Liquidators turned to DataXstream, an SAP professional services organization focused on technical consulting and integration, with particular skills in landscape design and implementation. After reviewing the business requirements and technical constraints, DataXstream proposed, and then deployed a completely virtualized SAP environment, covering Development, Quality Assurance, and Production landscapes. The resultant solution exceeded the needs requested by Lumber Liquidators:
|
|
- Leveraging DataXstream’s longstanding expertise in SAP, the solution was tuned specifically to support current SAP needs, while remaining flexible enough to grow incrementally as new deployment phases started.
- Utilizing VMware features such as DRS, SRM, and HA, the solution insured consistent SAP response to users, even during scheduled maintenance, or fail-over conditions.
As a result of working with DataXstream, Lumber Liquidators met their implementation timelines, budgetary forecasts, and improved the chance of adoption by its user community. Simultaneously the choice enabled its IT team to easily support the landscape without having to add more resources.
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.
SAP Upgrade Project Management Considerations
This is the first in a series of posts that I will write regarding upgrading your SAP system. 2010 is anticipated as the year of the upgrade (you heard it here first – maybe not) as many SAP customers saw an upgrade as an easily avoidable expense in the midst of the economic carnage of the last 12-18 months. Also, SAP is on a push to get customers off earlier releases and up to ECC 6.0 and various EHP (enhancement packs) to make upgrades a thing of the past.
Excuse a note of skepticism about the end-of-upgrades-as-we-know-them, I suspect the path and the mechanism to get new functionality will change. The text book methodology and approach will change, but I suspect SAP customers will be hesitant to let go completely of previous approaches to upgrades. Sounds like a topic for a future blog post.
In these posts I’ll address some of the upfront considerations before you embark on an upgrade, then progress on to ways to leverage some of your existing assets to make the process as successful as possible. Along the way I’ll discuss the impact on your SAP landscape, non-SAP systems, and other ongoing projects you may have in motion. As a wise man I once worked for said–and I’m paraphrasing–“we don’t want to rebuild the plane in midair.” Trying to get it in the hangar without passengers onboard is a noble goal, but perhaps not completely realistic.
This discussion is pitched at a fairly high level although an in depth discussion is easily set up by clicking here to contact us.
For more on SAP Upgrades download the white papers:
SAP Upgrade Checklist
Customization Risk Analysis in an SAP Upgrade Project
As always, comments and feedback are welcome, but I ask you to be civil. Your experiences are not the same as mine, I can learn from you and I hope you can learn a little from me. Let’s begin.
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.
