What Makes a Great ISV Enablement Partner?

DataXstream is a company that specializes in SAP and most readers of this blog are SAP professionals.  So, I have some shocking news for you–news SAP doesn’t want you to know.  Are you sitting down?  Good.

SAP isn’t the only software vendor out there!!

Shocking, I know.  But there are other software platforms than NetWeaver; software languages other than ABAP and Java; and there was a time in the not-too-distant past where the center of the SAP universe, HANA, didn’t even exist!

While you are coming to terms that SAP is not the be-all and end-all, I would like to point out that no modern software system exists in a vacuum.  Because of this fact, attention has to be paid to how software systems interact with each other.  There is a seemingly endless supply of enterprise software solutions that supplement existing functionality, introduce new functionality, improve the user-experience, and, in general, bring value to the enterprise.  SAP’s predominance in the enterprise software market means that it these new enterprise software solutions need to interact with SAP–either getting data from SAP or sending data to SAP (or both).

But, SAP is not an easy software system with which to integrate.  The depth of SAP product offerings and modules make learning how to properly merge SAP functionality with an external software system difficult.  SAP NetWeaver is not known as a particular open or easy-to-access platform.  And while I personally laud SAP for their decision to enforce proper multi-tier data access restrictions (i.e. no direct read/write database access), this decision makes the SAP learning curve especially steep.

Many software companies desiring to integrate their software solution with SAP choose a independent software vendor enablement partner.  So, what makes a great ISV enablement partner?

  • Functional Expertise: In order to make the most of an integrated software solution, you must understand the needs of the business user.  Once these needs are understood, you need to transfer these requirements into software functional units of work.  Finally, an end-to-end workstream is defined across all participant software systems that will deliver the required functionality to your customers.
  • Technical Expertise: The best end-to-end workstream definition is only as good as the framework upon which the integration executes.  A great ISV enablement partner understands all of the technical aspects of SAP NetWeaver integration and development.  They will use this expertise to design and implement a solid, robust, scalable technical integration solution.
  • Go-To-Market Experience: Once the solution has been designed and built, it will need to be made available to the market.  A great go-to-market strategy involves market analysis, promotion, and working with the SAP ecosystem including SAP partnerships and certification.
  • Technical Sales and Marketing Support: Even the best software solutions don’t sell themselves.  Your ISV enablement partner should be there throughout the customer sales process to answer any questions and remove any barriers to sale.
  • Flexible Partnering Agreements: A great ISV enablement partner will work with you to craft a partnership agreement that benefits all parties while giving your customer’s the world-class solutions and support that they need.

DataXstream has been a leader in SAP ISV partner enablement since 2005 and has assisted dozens of software companies successfully enter the SAP market. Contact us today, to find out how we can unlock the SAP world for you!

What Makes a Great SAP Integration Partner?

An SAP integration specialist’s responsibilities are to design and implement a robust, extensible solution that uses the appropriate standards and technologies to guarantee ACID programming guidelines (Atomicity, Consistency, Isolation, Durability) while leveraging the available programming interfaces to the best of their capabilities.  This may sound like a daunting task.  That’s because it is.  Integration is a very complex, specialized areas of expertise in the SAP ecosystem.

A great SAP Integration Partner will offer individuals that design and build integration solutions that adhere to the following concepts:

  • Robust – A good integration solution can recover from data and/or transmission errors. A truly robust solution should automatically attempt reprocessing where appropriate and, barring automatic processing, alerts the support personnel to the exception with context-specific data to assist in the exception resolution.
  • Extensible – Change is constant in the world of business.  A good integration solution is able to rapidly adapt to changes in process, requirements, and/or functionality.  More often than not, the individual that initially implemented the integration solution is not available to make the changes.  A combination of good design, process and procedure adherence, and documentation lowers the total cost of ownership for the integration solution.
  • Standards – Good integration partners understand standards, how they should be applied as well as their strengths and weaknesses.  Integration solutions that conform to standards are usually more robust and extensible, and therefore easier and cheaper to support, than their custom counterparts.
  • Atomicity – Robust integration solutions require atomic actions.  That means if one part of the transaction fails, the whole transaction fails.
  • Consistency – A consistent integration solution leverages the application programming interface to ensure that all business rules and processing logic are applied to the data prior to posting it to the database.  It is also important that data created via the integration solution passes the same validation and business rules as data created via the user interface.
  • Isolation – Great SAP integration partners understand how transaction isolation can greatly impact overall system performance.  Providing isolation means concurrent execution of data transactions results in a system state that would be obtained if transactions were executed serially–or in other words the interface can be executed in parallel, and therefore, take advantage of SAP NetWeaver parallel processing.
  • Durabilty – A durable integration solution is not affected by errors outside of the transaction–whether these errors be related to environment (power, network, database, etc.), data (business rules, missing data, incomplete data, etc.) or other factors.
  • Programming Interfaces (APIs) – A great SAP integration partner understands available programming interfaces and standards, their relative strengths and weaknesses, and how they interact with other components of the application.  Not all APIs are created equal and a great SAP integration partner will choose the API best suited for the integration solution.

DataXstream solution architects and integration specialists are trained in every one of these aspects and have the experience necessary to ensure every integration solution is a great one.

NCo 3.0 Error: Could not load file or assembly ‘sapnco_utils.dll’ or one of its dependencies

Recently I was deploying a Windows Service that uses SAP .NET Connector 3.0 on a fresh install of Windows (the specific version isn’t important, but it was Windows Server 2003).  I built my installer package, installed .NET Framework 4, and installed my program.  When it came time to execute my service, I received the following error message.

System.TypeInitializationException: The type initializer for
  'SAP.Middleware.Connector.RfcServerManager' threw an exception.
  ---> System.TypeInitializationException: The type initializer for
  'SAP.Middleware.Connector.RfcConfigParameters' threw an exception.
  ---> System.IO.FileNotFoundException: Could not load file or
  assembly 'sapnco_utils.dll' or one of its dependencies.
  The specified module could not be found.
at SAP.Middleware.Connector.RfcConfigParameters..cctor()
--- End of inner exception stack trace ---
at SAP.Middleware.Connector.RfcConfigParameters.Initialize()
at SAP.Middleware.Connector.RfcServerManager..cctor()
--- End of inner exception stack trace ---
at SAP.Middleware.Connector.RfcServerManager
.GetServer(String serverName, Type[] rfcFunctionHandlers)
at DataXstream.AwesomeProduct.InitializeSap()

What was really confounding was that the Fusion Log reported no .NET binding errors! So, what was going on?

[Read more...]

Five Tools all Junior SAP ABAP Developers Should Know

For those of you new to SAP, be you technical or functional, her are a five tools you need to know to successfully navigate through the SAP landscape.

*Disclaimer* These tools will not provide the answer to your problems, but they should give you insight and the ability to solve your problem.

[Read more...]

SAP NCo 3.0: How-to Pass Table Parameters to SAP RFC

Since I posted step-by-step instructions on how to build an NCo RFC client, the  request I most often get is how to populate and pass a table of data as a parameter to an SAP RFC.  In this blog, I will walk through the steps to pass a table parameter to from a .NET program to SAP via NCo 3.0.  I will not be covering the basics of how to set up NCo 3.0 as a RFC client as I have already covered that.

[Read more...]

SAP Tip Quick Hit: Location of saplogon.ini in Windows 7

Ugh.  I spent the last 10 minutes searching for saplogon.ini!!

I need to copy it to a Virtual Machine so I don’t have to type in all of the SAP system information.  As many of you know, SAP saves SAP Logon Pad entries in a file called saplogon.ini.  For many releases, this file resided in the C:\Windows directory.  Since Microsoft has began enforcing their improved security model, SAP has adapted and, therefore, moved the location of saplogon.ini to a directory that I can never seem to remember.  I have SAPGUI 7.20 running on Windows 7 (x64) and I find myself scouring my hard drive in search of saplogon.ini!  I have 38 versions of the file, but which is the right version? Don’t worry, I finally found the right one. But I have performed this search at least three times in the past year! I seem to never make a point to note the location of saplogon.ini.  I can’t be alone in this search.

So for future me and you, dear internet community, here is the location of saplogon.ini file in Windows 7 for SAPGUI 720:

[Read more...]

Web Dynpro Basics: Context and Binding

This is for those who are new to Web Dynpro programming. Here is an explanation of how to set up a Web Dynpro application using the context and binding the context to User Interface (UI) elements of the application. This is only a basic explanation to help set a foundation for understanding Web Dynpro programming. The 3 basic elements of a Web Dynpro application are windows, views and the context. The window is simply a container for a view. To assign a view to a window expand the views and windows under the section labeled ‘Object Name.’ Double click on a window and then drag and drop the view into the window. [Read more...]

It’s SAP Upgrade Time! Do You Know Where Your Customizations Are? Part 3.

In my final post on this topic, I will discuss some of the techniques that I use to “discover” information about customizations in an SAP system, even in the absence of any documentation.  The information available to be discovered may include such details as the object name, object type, user name of the person who made the last modification, date and time of the last modification, usage statistics, where-used, and for code-based objects, even the versions and their code differences.

[Read more...]

It’s SAP Upgrade Time! Do You Know Where Your Customizations Are? Part 2.

In my last post on this topic, I discussed two negative effects of customizations in an upgrade project – risk and cost.  I also discussed an obvious reason to eliminate unnecessary customization – the mitigation of risk and cost.

In this post, we will look at some of the customization areas which add risk and the cost to an upgrade project.

[Read more...]

Build an RFC Client with NCo 3.0 – A Step-By-Step Guide

The SAP .Net Connector 3.0 (NCo 3.0) offers many improvements over the 2.0 version of that product. Unfortunately, SAP no longer offers example .NET code.  This blog attempts to fill that gap by describing how to build a simple RFC Client using SAP .Net Connector (NCo) 3.0.  Click here to request a .zip file containing a copy of the source code.

The sample program displays details about companies defined by SAP. There are two BAPI calls involved, BAPI_COMPANY_GETLIST and BAPI_COMPANY_GETDETAIL.
Along with the SAP .Net Connector 3.0, we are using Microsoft Visual Studio 2010 and the Microsoft .Net Framework 4.0 to build our sample.  Prior to starting, you will have to download and install NCo 3.0 (OSS login required).
[Read more...]