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

Introducing SAP .NET Connector (NCo) 3.0

This past summer, SAP announced a new version of SAP Connector for Microsoft .NET — NCo 3.0.  SAP decided to give us an early Christmas present when they officially released NCo 3.0 on December 22, 2010.  You can download NCo 3.0 at http://service.sap.com/connectors (you will need an OSS logon).

Included in the downloads are documents that discuss the notable changes from .NET Connector 2.0 and a very comprehensive help file (in .chm format).  Noticeably absent are complete samples, although SAP claims that the included tutorial will be updated.

Additionally, I already have my first NCo 3.0 project under way, so check back soon for more information about NCo 3.0!

Happy Coding!

[UPDATED]

Additional Information

Follow these links for more information about NCo 3.0 programming:

SAP Data Migration – Answering the Important Questions (Part 1)

It is data migration time on your SAP business project.  Whether your project is implementation, acquisition, or merger, the goal is pretty much the same: the seamless inbound acquisition of master and transactional data from one or more external data sources while ensuring that this activity has minimal impact on the rest of the business.  This is where we attempt to move years of neglected master and transactional data from a loosely structured, anything-goes legacy system into a very tightly integrated and highly structured SAP system.  You must consider the likelihood that the concept of master data management had not been invented yet when the legacy or source system providing your data was implemented.

How much data to move? How much data to leave behind? What to automate, and what to execute manually?  How to gracefully orchestrate and execute a data migration cutover from one system to another?  Where and how to fit the data migration plan into the overall business implementation plan?  How to continue to run the business during the data migration phase of the business project implementation? These questions are all part of the planning fun!

[Read more...]

Using Native SQL in an ABAP Proxy

Recently, I was looking at a requirements document to build an interface to an external system that wants to query customer master data by the customer first name and last name.  As I read this, there were a cacophony of thoughts, all demanding equal attention, racing through my head:

  • How will I ever match the inbound interface parameter “Tom” with “TOM”, or “tom”?
  • How will I ever match the inbound interface parameter “Smith” with “SMITH” or “smith”?
  • The ABAP WHERE clause is not case-INsensitive.
  • There could be hundreds of customers named Tom Smith.
  • KNA1-NAME1 and KNA1-NAME2 are not indexed fields.
  • And no, we are not storing any portion of either first or last name in an existing indexed field like SORTL.
  • There are well over one million customers in the database.
  • We have already decided to use PI for all interfaces.
  • I will have to buy the BASIS team a case of beer to get them to agree to create indices on the fields KNA1-NAME1 and KNA1-NAME2 in a table with over one million records.

I arrived at the conclusion that I need a case-insensitive database query, along with database indices created for the fields KNA1-NAME1 and KNA1-NAME2.

But, what is a case-insensitive WHERE clause?  A little research and help from colleagues revealed that many had gone before me, and this was nothing new.  To implement a case-insensitive WHERE clause in ABAP, you simply needed to use the native SQL UPPER() construct. The database system that is being used is Microsoft SQL Server, but the UPPER() function and its syntax is similar across different database platforms. This seemed like an easy nut to crack. But, as I soon found out, I actually had a lot to learn.
[Read more...]

The Ergonomic User Interface

Every Monday morning I hop on a plane, arrive at my destination city, pick up a rental car, and drive to my client’s site.  The car rental company gives me a different make and model car every week.  And yet, somehow, I am successfully able to open the car, adjust the seat and mirrors, start the car, shift gears, and drive.  I can also operate the radio, air conditioning, heat, windshield wipers, and headlights.

Now, put me behind a keyboard in front of a computer application which I have never seen before. My user experience is all over the map – somewhere in the continuum between most excellent and very poor.  Some application user interfaces are extremely intuitive, well-designed and easy to navigate, logically follow the business process flow, and provide real meaningful help when needed.  Other application user interfaces are extremely difficult to navigate, are not intuitive, do not follow a logical business process flow, and offer little or no meaningful help. And sometimes in these difficult user interfaces, not only has the location of the steering wheel been moved to a totally unsuspecting location, but its appearance has been changed so that, even when I see it, I do not even recognize it as being the application’s steering wheel.

A well-engineered user interface is no accident.  It doesn’t just magically happen.  It must be woven into the fabric of the design and the code; and it should never be shoe-horned into the application as an after-thought.   It takes a lot of up front planning, designing, testing, functional effort and technical effort to produce a really good application user interface.  And yes, designing, building, testing, and implementing a good user interface for your application will extend the delivery time of whatever it is that you are building.

Why is a well-designed and ergonomic user interface so important?  You could have built the best application ever developed.  But if it is unusable, it will never get very far.   Countless hours are lost every day as thousands of frustrated users spend extra time and effort wrestling with poorly designed user interfaces, rather than focusing on their jobs.  And when the frustration levels reach a certain trigger point, the users will seek out and find alternative ways to perform their duties.

Here are a few examples of some very interesting user interface experiences that I have personally encountered.

[Read more...]

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

Changing The Function Interface of Web Service Enabled Functions

Today, I got an email from one of my co-workers at my client with a very good question.  This developer had created an ABAP function to return SAP data.  Then, he exposed this function as a web service. Due to changes in functional scope, he had to change the function interface.  After he made all his changes and unit tested the ABAP code, he was surprised to find that his web service was still adhering to the old function interface.  He tried deleting and recreating the web service, but ran in to problems.  He was stuck in a pickle and needed a little push in the right direction.

[Read more...]