SAP EDI Blog | SAP Experts: Consulting | Integration

What Makes a Great ISV Enablement Partner?

May 16, 2013 by Craig Stasila Leave a Comment

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!

Filed Under: Blog, SAP ABAP Blog, SAP EDI Blog, SAP Functional, SAP Interface Blog, SAP Java Blog, SAP PI Blog, SAP Project Management, SAP Strategy, SAP Technical Tagged With: Craig Stasila, DataXstream, Integration, Interface, Interface Experts, ISV, NCo, NCo 3.0, Process Integrator, SAP, SAP .Net Connector, SAP Integration

What Makes a Great SAP Integration Partner?

May 14, 2013 by Craig Stasila Leave a Comment

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.
Durability – 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.

Filed Under: Blog, SAP ABAP Blog, SAP Basis Blog, SAP EDI Blog, SAP Functional, SAP Interface Blog, SAP PI Blog, SAP Project Management, SAP Strategy, SAP Technical Tagged With: Craig Stasila, DataXstream, Integration, Integration testing, Interface, SAP, SAP Integration, SAP PI, SAP programming, SAPPHIRE, SAPPHIRENOW 2013

SAP PI Dilemma: How to Get Production IDocs for Testing

April 22, 2013 by Michael Champion Leave a Comment

Every SAP developer/consultant knows that to be able to test new programming logic and/or configuration efficiently and thoroughly, sufficient test data is required to ensure quality. I have worked on several SAP PI projects and have run into the issue of not having great test data (or, for that matter, any test data!) in my development/test environment. If you’re ever in a spot where you need to test IDocs from a different system, here is a step-by-step guide on how to get them without having to perform much setup.
[Read more...]

Filed Under: Blog, SAP EDI Blog, SAP PI Blog, SAP PI Blog, SAP Technical, SAP Testing, SAP Testing, Uncategorized Tagged With: DataXstream, Interface testing, PI, PI Mapping, Regression testing, SAP PI, SAP testing, Test data, Unit testing, XI/PI

What Does a Successful SAP IIOD Implementation Entail?

January 17, 2013 by Craig Stasila 3 Comments

In my last post, I discussed how SAP’s planned incorporation of recent acquisitions (Crossgate and Ariba) into the SAP Business Network offers a logical advancement in B2B communications. The SAP Information Interchange OnDemand (IIOD) integration model improves on the familiar point-to-point topology by pushing customer-specific logic to inside the business network (aka the “cloud”). Doing this simplifies the integration that any one company using the SAP Business Network needs to maintain.

Chances are, however, that your organization already has a significant investment in your existing B2B communication strategy. Even if you are new to B2B communication, an SAP IIOD implementation is still an implementation project, including all the normal responsibilities, risks, and (hopefully) rewards. SAP Business Network’s value lies in its ability to simplify the on-boarding of new business partners while streamlining the maintenance of your existing B2B network, but that doesn’t mean it is easy (or free) to implement.

While most I’ve encountered understand that there is no such thing as a free lunch, I’ve found there to be much misunderstanding as to what is even on the menu. I will attempt to explain an SAP IIOD project, its deliverables, and provide roles and responsibilities for the parties involved.

(null)

Filed Under: SAP EDI Blog, SAP IIOD, SAP Interface Blog, SAP PI Blog, SAP Strategy, SAP Technical, Uncategorized Tagged With: Ariba, B2B, Business Network, Craig Stasila, Crossgate, DataXstream, SAP II, SAP IIOD, SAP Information Interchange, SAP Information Interchange OnDemand

SAP Information Interchange OnDemand (IIOD) in a Nut Shell

May 23, 2012 by Dataxstream Leave a Comment

You’ve seen how we can rapidly integrate and deploy SAP IIOD across your entire business network, but you still may have questions how IIOD can streamline communication between you and your trading partners. Let our friends at SAP fill in the blanks.

Filed Under: Blog, SAP EDI Blog, SAP IIOD Blog, SAP PI Blog, SAP Strategy, SAP Technical Tagged With: Quick Connect, SAP, SAP IIOD, SAP Information Interchange OnDemand

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

February 28, 2012 by Craig Stasila 6 Comments

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:

SAP IDOCs for Customer Number with different Sales Organizations to different External Partnerships

February 7, 2012 by Dick Koch Leave a Comment

Have you ever implemented an outbound EDI process from SAP for a single customer number where the customer has multiple EDI trading by Sales Organization or Division? It can be done. In order to accomplish this you will need to create separate output types for each Sales Organization/Division and then set up the Access Sequence/Output Determination in order to create the IDOC for each partnership. You can then use the Message Variant and/or Message Function fields of the Partner Profile to differentiate between the two Sales Organizations/Divisions. Finally, you would set up your EDI Mapping to look at the Partner Profile fields in order to route it to the correct partnership. Let’s take a closer look at this process.

Let’s say that Customer 15 in your SAP system buys products from your company. It sends inbound EDI Orders to you using three different partner IDs because they have 3 internal divisions and they want all transactions to be separate. You want to keep all sales data for this customer under one customer number in your SAP system and just separate them by a different division. You are required to send out EDI invoices to this customer, but they must go to the correct EDI Partner ID. Let’s say you would normally use the Standard SAP Output Type RD00 and Access Sequence 0003 (Sales Org, Distribution Channel, Division, Customer Number) for producing your INVOIC IDOCs. [Read more...]

Filed Under: Blog, SAP EDI Blog, SAP Functional, SAP Interface Blog, SAP PI Blog, SAP PI Blog, SAP Technical, Uncategorized Tagged With: ALE, DataXstream, EDI, IDOC, Interface, PI, SAP, SAP Integration, SAP PI, XI, XI/PI

SAP EDI EDPAR Table Walkthrough – How to Cross Reference External Customer Number to SAP Customer Number (Part 2)

February 1, 2012 by Dick Koch 3 Comments

Let’s say you are receiving EDI ANSI X12 850 Sales Orders from you customers that need to be uploaded into your SAP System using the ORDERS05 IDOC. Most customers will have their own internal customer numbers that they send in their EDI transmissions to represent the Sold-To and Ship-To partners.

How do you convert these external customer numbers into your internal SAP customer numbers?

Some may hard code these conversions into their EDI maps. This approach can be very high maintenance as customers can add new ship-to locations or reorganize their internal numbers which would require changes to your maps.

Others may set up a cross reference table within their EDI translation table to perform the conversion. This works well at times, but then you are at the mercy of your EDI group to update the table with any new additions or changes to existing entries. [Read more...]

Filed Under: Blog, SAP EDI Blog, SAP Interface Blog, SAP PI Blog, SAP Technical Tagged With: ALE, DataXstream, EDPAR, IDOC, Integration, Interface, SAP, SAP External Cross Reference, SAP Integration, VOE4, XI/PI

SAP EDI EDPAR Table Walkthrough – How to Cross Reference SAP Customer Number to External Customer Number (Part 1)

January 26, 2012 by Dick Koch 1 Comment

When creating IDOCs in SAP to send Invoices to customers via EDI you will likely have to send the customers their internal partner numbers on the EDI ANSI X12 810 Invoice Document. In almost all cases this will not be the same as the SAP partner numbers. So how can we set up a cross reference of SAP and external partner numbers? Well, the answer is simple because SAP has set up a utility to handle this for you. All you need to do is populate the EDPAR table in SAP using the VOE4 transaction. Once this is completed the IDOC_OUTPUT_INVOIC function module will read the EDPAR table when the Invoice document output is processed and populate the LIFNR element of the E1EDKA1 or E1EDPA1 segments of the INVOIC IDOC with the external partner number. Entries in EDPAR can be set up for multiple partners including the Sold-to, Ship-to, and Bill-To numbers so that external customer number cross-references can be passed on the IDOC if needed.

Let’s look at how this process works. Let’s say we have created an invoice document in SAP. In this case, the Sold-to, Ship-to, and Bill-to partners are all SAP customer number 15. If we want to create an INVOIC02 IDOC on which the external customer numbers are populated for all three of these partners we would have to set up three EDPAR entries as displayed on the below screen shot. The Customer field will contain the SAP partner number (Sold-to, Ship-to, Bill-to). The Ext. Function field will contain the Partner Function (SP = Sold-to, SH = Ship-to, BP = Bill-to). The External Partner field will contain the external partner number that the customer is expecting on the EDI file. And the Int. no. field will contain the SAP partner number (Same as the Customer field).

SAP Standard Sale Area Cross Reference For Inbound IDOC Processing

October 19, 2009 by Dick Koch Leave a Comment

Cross Reference To SAP Sales Area From External Customer Number – SAP EDSDC Table

If you have ever converted an external file into a SAP Sales Document IDOC (ex: ORDERS05) you may have hard coded the E1EDK14 segments of the IDOC which specify Sales Area and order type for the SAP Sales Document. However, these segments are not required if you populate the E1EDKA1-LIFNR segment of the IDOC with the External Customer Number and populate the EDSDC table with the Sales Area and Order Type for the customer. Your SAP system contains a standard utility that converts the External Customer Number to the Sales Area values and Order Type value contained in this table.

Sales Area Cross Reference From IDOCs ORDERS05 and DELFOR02

This utility is available in the standard SAP package to convert External Customer Number to SAP Sales Area when processing inbound IDOCs (ex: ORDERS05, DELFOR02) from non-SAP systems. It eliminates the need to add E1EDK14 segments to the IDOC as it populates the Sales Organization, Distribution Channel, Division, and Sales Document Type using the entries in the EDSDC table which is populated using transaction VOE2. In order for this process to work, you must have the Customers External number populated in the E1EDKA1-LIFNR field of the IDOC where E1EDKA1-PARVW is ‘AG’ and the EDPAR Customer Conversion table set up to convert the Customer External number to the SAP Customer number. See my blog ‘SAP EDPAR Table – External Customer Number cross reference to SAP Customer Number’ for instructions on the External Customer Conversion. By properly doing this, the standard SAP function module will use the EDSDC table to convert the External Customer Number to the SAP Sales Area and Document Type. The following instructions will explain how to populate the inbound IDOC and the EDSDC table.