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 an 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!

 please request more information here or email us at Info@dataxstream.com

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...]

SAP TechEd 09 Demo Jam Liveblog Recap

This blog is a recap of the liveblog of the  SAP TechEd 09 conference Demo Jam. To read in chronological order, start from the bottom and work your way up.

[Read more...]

SAP TechEd 09 Keynote Address Liveblog

Liveblogging SAP TechEd 09

Are you stuck in your cube while Bob from BASIS is heading to SAP TechEd 09 in sunny Phoenix?  Are you afraid that you’ll miss out on all the sun and fun?  While we can’t send the sun, we’ll try to bring you the fun.  DataXstream will be liveblogging at SAP TechEd 09.

Head over to live.dataxstream.com on Tuesday, October 13, 2009 to get up to second updates from the show.  We will be getting our liveblog on starting at 8am PDT (that’s 11am for you right-coasters) for the general keynote session.  We’ll also be liveblogging from SAP TechEd 09 Demo Jam at 8pm PDT on Tuesday.  The Demo Jam promises to be a great time, so plan to join us online after you put the kiddies to bed!

This is our first foray into liveblogging.  Hopefully it will go off without too many technical glitches.  We hope you’ll enjoy following the events with us!

Server Programming in JCo Part 3

This is a continuation of Server Programming in JCo Part 2. In this post, I will deal with receiving and parsing the actual call from SAP.

In the previous post, the setup of the JCO.Server class was explained. To actually do anything with this class, we have to override the handleRequest() method. This method gets called when ever the SAP system with the proper credentials contacts your server.

In the handleRequest() function, There are 2 important tasks that are almost always included:

  1. Get the parameters for input, output, and table structures using the JCO.Function class
  2. Checking the function name to make sure the right code is run

[Read more...]

Server Programming in JCo Part 2

This is a continuation of Server Programming in JCo Part 1. In this post, I will deal with the setting up the constructs of the java program acting as the server.

The key Java object in JCO server programing is the JCO.Server, which is easy to use, but very powerful. At a high level, only these three things are needed to setup the server class:

  1. extend the JCO.Server class
  2. in your constructor, call one of the JCO.Server constructors
  3. override the handleRequest(JCO.Function function) method

Below is an example of a basic server setup. When the Server is running, all requests coming from the configured SAP system, will be sent to the handleRequest() function

[Read more...]

Server Programming in JCo Part 1

the SAP Java Connector, or JCo library, is an SAP delivered tool for connecting programs written in Java to the R/3. Most articles deal with external applications connecting to SAP R/3, but JCo provides the capability for SAP to call your java application as well. In this blog post, we’ll cover how to correctly setup SAP to call your java application.

In this first installment, I will just cover basic architecture and connection needs.
To create and run a java server successfully, we need the following two things:

  • Proper connection Parameters
  • A function template of your function in R/3

Proper Connection Parameters

In order to connect and use the JCo Server with R/3, the following items must be known:

  • Gateway host – The SAP gateway server name or IP address
  • Gateway Service Number – The service number is related to the SAP system number and starts at sapgw00
  • Program ID – The Program ID must match the Program ID registered in SM59

This information is available most likely from a Basis administer. The RFC registration matching is a common problem. The a sample Program ID is shown below. This HAS to match the program ID you start your JCO.Server object with.

SM59 Registration Configuration

SM59 Registration Configuration

Functional Template

A JCo server needs to have the skeleton of the program in R/3. SAP cannot just call your external java program without the import, export, and table parameters defined within the system. Instead of creating a custom RFC for this example, I’ll use a pre-existing one. remember, we are only using the import, export, and table parameters, the code is running on our java server. The BAPI we are going to use is BAPI_CUSTOMER_GETDETAIL.

After these two things are in place, we are ready to start coding.

The next post will cover:

  • JCO.Server Object
  • JCO.Repository Object
  • JCO.Client Object

The next posting is Server Programming in JCo Part 2