IDoc Has Left The Building
SAP IDocs are a tried and true interface methodology. But as with any interfacing technology the most brittle component is the connection between the two systems (in the case, SAP and the subsystem). In scenarios where SAP is sending IDocs to a subsystem via the transactional RFC, one question is paramount:
How do you know when an Outbound IDoc has physically left SAP?
It’s a simple fact that if your subsystem never receives an IDoc from SAP, the subsystem will not be able to route or process the IDoc. I have always gone by the notion that once the subsystem has successfully received the IDoc, the subsystem now has all the responsibility to process and route the IDoc, but before that time, SAP has the responsibility to ensure that the IDoc is fully dispatched. The subsystem should have processes in place to determine if the IDoc has been received at the target system successfully or not. In this blog I will focus on the handshake between SAP and the subsystem. This will entail Outbound IDoc status and a couple of batch jobs that should be setup to ensure a better chance of a successful handoff between SAP and the subsystem.
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
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!!
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.
SAP Standard Sale Area Cross Reference For Inbound IDOC Processing
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.
SAP Standard Customer Cross Reference For Inbound IDOC Processing
Converting External Customer Number To Internal Customer Number – SAP EDPAR Table
Have you ever had a project where you are converting a customer file into an SAP Sales Document IDOC (ex: ORDERS05) and the customer file contains their Internal Customer Number? So you need to determine what the SAP Customer Number will be on the IDOC. If you are not familiar with the SAP interface process you may hardcode the SAP Customer Number or create external tables in your third party mapping software to accomplish this conversion process. However, this involves customer specific logic or updating the tables with your SAP Customer Numbers and having a process to maintain this table as new SAP Customer Numbers are created. There is a much easier way to perform this conversion with no additional coding as it is a standard SAP utility.
Customer Conversion For IDOCS ORDERS05 and DELFOR02
This utility is available in the standard SAP package to convert External Customer Numbers to SAP Customer numbers (Sold-To, Ship-To, etc.) when processing inbound IDOCs (ex: ORDERS05, DELFOR02) from non-SAP systems. When working with data that will be imported into SAP via IDOC format the data usually contain your customers external sold-to and ship-to numbers and not the associated SAP customer numbers. Therefore, you would need to convert this External Customer Number to your internal SAP Customer Number. Instead of creating cross-reference tables or conversion routines in your third-party translation software you can populate the E1EDKA1-LIFNR field of the inbound IDOC with the External Customer Number and use transaction VOE4 to populate the EDPAR table. By properly doing this, the standard SAP function module will use the EDPAR table values to convert the External Customer Number to the SAP Customer number. The following instructions will explain how to populate the inbound IDOC and the EDPAR table.
DataXstream Press Release – Xstream Connector from DataXstream Certified by SAP
Williamsburg, VA: February 20th 2009
Xstream Connector from DataXstream Certified by SAP SAP has formally certified DataXstream’s Xstream Connector product and Cforia’s connector integration. This is the culmination of extensive joint development by the two companies and provides customers with a standard, repeatable and fully supported mechanism to transfer data from SAP to Cforia’s application.
The Xstream Connector provides a packaged software solution that can be installed at a client site and have fully functional connectivity and data transfer established between an SAP system and Cforia in less than a day. Delivered via the SAP AAK (Add-on Assembly Kit) the Xstream Connector uses standard SAP messaging and output control techniques to seamlessly move data from SAP to Cforia in near real-time. The Xstream Connector contributes to the shortening of overall Cforia implementation timelines allowing SAP customers to rapidly reap the benefits of enhanced work flows focused on driving cash flow optimization.
About DataXstream, LLC Since 1996 DataXstream has been providing world class integration and infrastructure consulting services to companies running SAP. DataXstream specializes at integrating heterogeneous platform landscapes to deliver seamless business solutions. In recent years the DataXstream portfolio has expanded to include software development and certification for SAP complimentary products. DataXstream is a preferred vendor and referral partner for SAP.
About Cforia Software, Inc Cforia Software, Inc. (Cash Flow Optimized, Real-time Information Access) develops solutions that enhance cash flow management. Cforia’s software products extend the functionality of accounting systems like SAP, Oracle, PeopleSoft and JD Edwards. Cforia’s customers are found in North America and Europe.
DataXstream Announces Virtual Integration Infrastructure at SAP® TechEd 2008 Las Vegas
Customers Can Integrate Now with Virtual Integration Infrastructure from DataXstream
LAS VEGAS, NV – Sept. 9, 2008
DataXstream today announced at SAP® TechEd 2008 Las Vegas availability of its Virtual Integration Infrastructure (VII): a powerful integration platform delivered as a utility service. DataXstream VII provides simplicity and affordability by pairing a comprehensive hosted integration platform with DataXstream’s deep integration experience.
“This is a great opportunity for DataXstream to maximize the value we bring to customers,” said Tim Yates, DataXstream CEO. “Our Virtual Integration Infrastructure allows us to implement full-functioned, end-to-end enterprise application integration (EAI) infrastructure in a matter of weeks. With DataXstream VII we free customers from the burdens of implementing and managing integration scenarios. We enable their IT resources to focus on activities that provide greatest business impact.”
The Virtual Integration Infrastructure (VII) by DataXstream is the world’s first offering in the burgeoning Middleware-As-A-Service (MAAS) market. By leveraging the first full-functioned EAI platform available as a service, DataXstream delivers world-class integration capabilities at a fraction of the cost and time of a traditional implementation. This type of utility based computing in the cloud is gaining momentum because it lowers development and support costs while meeting business requirements. MAAS is especially suitable for organizations that would not like to maintain an in-house data movement and transformation infrastructure.
In addition to a world-class technical solution, the VII platform is supported by DataXstream’s deep integration expertise. DataXstream integration specialists work with customers every step of the way—interface design, build, implementation, and support—to ensure integration scenarios not only fulfill the business needs for system integration, but do so in a cost-effective, robust, and secure manner.
“DataXstream VII scales with you,” said Craig Stasila, principal technical architect. “Our support team monitors system usage and availability to ensure that you have the resources you need, when you need them.”
DataXstream’s utility pricing means you only pay for the resources you use–similar to your mobile telephone bill. All inclusive pricing means an end to up-front software costs and maintenance fees, the overhead of server maintenance, hardware and operating system support, and the ever-increasing heating and cooling requirements of a modern IT infrastructure. DataXstream VII offers a real cost savings over any alternatives.
SAP TechEd 2008 is SAP’s largest ecosystem education event of the year, which is being held Sept. 8-12. DataXstream is exhibiting at TechEd in booth 23.
About DataXstream, LLC Since 1996 DataXstream has been providing world class integration and infrastructure consulting services to companies running SAP solutions. DataXstream specializes at integrating heterogeneous platform landscapes to deliver seamless business solutions.
In recent years the DataXstream portfolio has expanded to include software development and integration of products complementary to SAP applications.
DataXstream is a participant in the SAP Referral program.
SAP and all SAP logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries. All other product and service names mentioned are the trademarks of their respective companies.
DataXstream Can Integrate Anything To SAP – Even A Toaster!
Why would you integrate a toaster with SAP?
SAP integration is our specialty. We figure that if we can integrate SAP to a toaster, we can integrate SAP to anything! From shop floor-automation, warehouse automation, accounts receivable, human resource management systems and, well, toasters, DataXstream is the leader in SAP integration.
How do you integrate a toaster with SAP?
How did we integrate SAP to a toaster? First, we created a custom ABAP application on our SAP R/3 4.7 Enterprise application server. This custom program calls a RFC on our SAP Netweaver Exchange Infrastructure 3.0 (XI) server. The XI server converts the RFC call into a web service XML message. The web service message is sent to a custom web service application implemented on Microsoft IIS 6.0. The web service application receives the XML message and uses a .NET DLL to communicate with a programable logic contrller (PLC) server. The PLC server communicates with a PLC that controls a stepper motor. The stepper motor is attached to the handle of the toaster. The handle is lowered to start the toaster and raised when the appropriate amount of time has elapsed. In addition to the SAP integration, DataXstream resources handled every step of the process including .NET programming and hardware fabrication.
 |
 |
