tips and tricks for building erp interfaces in mii · pdf filetips and tricks for building erp...

Tips and Tricks for Building ERP Interfaces in MII

Applies to: SAP-MII (versions 11.5 and higher), SAP ERP (R/3 4.6B up to ECC 6.0). For more information, visit the Manufacturing homepage.

Summary The document will provide some useful techniques learned from years of building Lighthammer/xMII/MII transaction based ERP interfaces. Learn to use ERP functionality to avoid difficulties in building Transactions and for testing. It also provides some methods of testing the BAPI and RFC modules using MII and the ERP system.

Author: Michael Appleby

Company: SAP Labs, LLC

Created on: 31 December 2008

Author Bio Mike Appleby, Sr. Solutions Architect, SAP-MII, recently joined SAP, having spent the last 3 years developing MII applications for SAP customers in diverse fields including Oil & Gas Refining, Electronics Manufacturing, Steel Foundry and Products, Thermoplastics Production, and Pharmaceuticals. He has a BS in Electrical Engineering from the University of Delaware. He has 10 years experience in IT and almost 20 years combined Manufacturing and Project management experience. He reports to Jeremy Good, Manager – Partners & Field Enablement Services.

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 1

https://www.sdn.sap.com/irj/sdn/bpx-manufacturing


Table of Contents Overview.............................................................................................................................................................3

Getting Started ................................................................................................................................................4 BAPI/SE37 Testing in SAP ERP..................................................................................................................................5 Confirmations in ERP.................................................................................................................................................11 Confirmations via MII .................................................................................................................................................16

Copyright...........................................................................................................................................................19



Overview One of the main uses of SAP-MII is to connect to SAP-ERP in order to retrieve information and to upload or update with information drawn from other sources. These sources can be data historians, test systems such as LIMS, or user interfaces for direct data entry. A common method for performing the data retrieval and updates is through the use of BAPI (RFC) calls. Many folks building these interfaces (including myself when I started) are not that familiar with the core SAP ERP functions for which the BAPI/RFC functions were built. This document is written to pass on some of the basic processes used by this former consultant when working on customer projects. Not all of these tips will be technical in nature. Some will also deal with consultant/customer interactions.

This is not meant to be a primer on building transactions, although there are going to be some items that will be useful and perhaps insightful for a developer. Nor is it intended as an instruction book on SAP ERP systems. Some small degree of familiarity with SAP ERP functions, navigation and transactions is assumed, but for the most part the instructions will be on the step by step level.

Notes:

1. ECC 6.0 will be used for examples and graphics, but the general concepts can be applied to earlier versions of the ERP. Some of these basic concepts have been applied to SAP R/3 4.6B.

2. Examples for MII will be using version 12.0.4 and 12.0.5, however the general approach can apply to versions 11.5 (and somewhat to even earlier versions). When references are made to the MII Workbench, it is also meant to include the version 11.5 equivalent, usually the Business Logic Services – Logic Editor.

3. BAPI (Business API) is a subset of the RFC programs available to outside applications including SAP-MII. In most cases, the terms BAPI and RFC are used interchangeably. In specific cases on the ERP side where they are not interchangeable, the differences will be noted.

4. The transaction BAPI which triggers the BAPI Explorer will be used throughout. A related transaction, SE37, performs many similar actions but applies to the entire set of available RFC programs. In general, reference to BAPI transaction code can be used interchangeably with SE37. The step by step instructions will be specific to BAPI Explorer. The design and layout of SE37 are different, but the same capabilities are there. They are just not as easy to use or even find.



Getting Started

When building an interface to SAP for a customer (using this document), an SAP-MII development system and an ID and Password into the ERP system are required. Depending upon the security organization involved and the rules which apply, there may be some limitations upon the pool of BAPI/RFC functions available to the developer. Use a meaningful name for the Alias, especially if there will be access to multiple systems from the SAP-MII server. A general name such as SAPJCO is fine. When moving applications to test or production, the Alias can be modified to point to a different SAP Client/System without changing your transactions. Names, which include terms such as ERPSandbox, will cause extra work when migrating to test or production or possible confusion if unchanged in production. Depending upon the complexity of the client ERP environment, names may be more complex, but try to keep them as simple and unrelated to their environment (sandbox, dev, test, prod, etc).

The ID used by SAP-MII to connect to the ERP system should be dedicated solely for the use of SAP-MII. The developer should also be able to use that ID and password to sign into the ERP system. The ID should have the same permissions for executing BAPI/RFCs from within the ERP as it does from SAP-MII. That is not always the case when dealing with Security. They can and often do limit access to the ERP to external only. Then the instructions and tips herein will be useless.

Note: Frequently the hardest and longest duration task on a project is getting the security permissions to access SAP, particularly when moving to production systems. It can’t be emphasized enough: Get the paperwork or request submitted as early as possible in the project. Get the client to realize the possible delays to the project by connector/security issues and get their support to help push the request through. This can also be true for other systems including data historians, databases, quality systems, etc. Get your connections established first!

Figure 1 Testing the Connection



Once the developer has the ID and password for MII, a SAP System Alias is created in SAP-MII (Data Services - SAP Server Editor) and then most likely tested by building a transaction with a single JCo Interface action block. In the Configure Object window, use the newly created Alias populate Search Pattern with something simple such as “BAPI_MATERIAL_*” or “RFC_READ_*”, then click the Get List button. If they return a list of function names in the bottom window, you have a successful connection. If an error message is returned such as:

Figure 2 No Function Found Error Message

This means that no functions were found meeting your search criteria. Change your search criteria to “BAPI*” or “RFC*” and retry. If the same error message continues to appear, then most likely the security (permissions) associated with the ID need to be changed to allow access to the BAPI/RFC pool.

Once a good connection is established to SAP and a list of valid RFC functions has appeared, the BAPI/RFCs can be tested. Close the Workbench.

BAPI/SE37 Testing in SAP ERP

Once the SAP System Alias has been tested and the credentials have been validated externally, it is time to move to the SAP ERP system.

There are two very good reasons to making this the next step. The first reason is to remove SAP-MII as a factor in the execution of the BAPI. This is not just for ease of troubleshooting. It is also a method of demonstrating to a customer or client that a BAPI works (or doesn’t) by itself. There are times when a client sees that a BAPI call from MII fails to execute properly and immediately decides that it is due to MII. This approach prevents that, all too frequent, disagreement.

Second, it shows which BAPI functions are available to the ID used by MII. Depending upon which version of ERP is installed at the client, there may be desired BAPI functions which were not part of that version. This may force the client to develop custom BAPIs, direct table reads, SQ01 queries or other alternatives to a standard BAPI that became available in a later version of ERP. It can also add reasons to update to later version of the ERP, though unlikely to be a primary motivation.

Second, it allows the developer to test quickly and frequently, and review the results more quickly than in MII. As part of this testing scenario, confirmations created directly in the ERP system should be reviewed and compared to those generated in the BAPI Explorer. Clients often have data requirements for confirmations that vary from a standard or minimal confirmation configuration.

Go to SAP Login (SAPGUI) and logon to the SAP ERP system specified in the Alias using the same credentials. In the Transaction entry box, type BAPI and hit enter. If the Transaction entry box is not visible, click on the triangle icon on the row of icons to expand it.



Figure 3 ERP Top Menu

The BAPI Explorer screen will be displayed with the Hierarchical tab already selected. If that is not the default, select the Hierarchical tab. The Alphabetical tab displays the BAPIs in alphabetical order as you would expect. But the alphabetical order is not done by the exact BAPI name, but rather by a group classification. For example, all the Production Order Confirmation BAPIs belong to the group named ProdOrdConfirmation. Generally, the Hierarchical view is usually more useful, but that is also a somewhat personal decision.

The BAPI Explorer is for the BAPI subset of the RFC pool. For the entire pool of functions (including all RFC functions), another transaction (SE37) is used. SE37 will be discussed after the BAPI Explorer along with the differences between the two. For this next part, a simple Production Order Confirmation using Time Tickets has been selected as the demonstration BAPI. Find and select in this order (see Figure 4):

1. Production Planning and Control

2. Production Orders

3. ProdOrdConfirmation

4. CreateTimeTicketMultiple

5. Folder tab for Right hand window labeled “Tools”

6. In the Tools Selection window, click on “Function Builder”

Note: There are a number of Production Order BAPI functions available for use. The ones of main interest (in this document) are:



• BAPI_PRODORDCONF_CREATE_HDR (One or more confirmations at the Order level)

• BAPI_PRODORDCONF_CREATE_TE (One or more confirmations at the Operation level of an Order with net time value entries for up to 6 confirmation activities. Default activities are Conf_Act_1 is Setup, Conf_Act_2 is Process, and Conf_Act_3 is Teardown.

• BAPI_PRODORDCONF_CREATE_TT (similar to …CREATE_TE except that standard times can be recorded with start and stop times associated with the confirmation activities in addition or in place of the net time value entries). For the purposes of this demonstration, this BAPI will be the one used.

Figure 4 BAPI Explorer Use

At this point, there are several useful options available. First feature for discussion is the Single Test button. This feature allows testing of the BAPI with the results available in SAP.

[A word of caution is in order. This can (and, by default, will) actually execute the function. In this particular case, a Production Order Confirmation will be performed. If a customer logs in under their own ID, which they will sometimes do, make sure they are in a sandbox or development environment or alternatively, can back out (reverse) the confirmation afterwards. I don’t recommend the latter choice, but customers sometimes want a production demonstration.]



Click on the Single Test button. An initial screen will open up:

Figure 5 Initial Production Order Confirmation Screen (BAPI)

This BAPI can record partial confirmations (Operation step within an order’s routing) or final confirmations. Typically it is used to record partial confirmations at the Order-Operation level. This example will assume partial confirmations rather than final. At a bare minimum, you need a quantity for Yield, Rework, or Scrap, an Order number, and an Operation number for partial confirmations. The confirmation number is already assigned within the ERP system for each Order/Operation pair. Initially there is a counter value of zero which will increment with each confirmation performed. If desired, the transaction can be executed in an uncommitted mode by entering an ‘X’ in the TESTRUN field. Click on the icon in the Value column associated with TIMETICKETS.

Enter an order number in ORDERID, an operation in OPER, and a quantity in one of the three confirmation categories (YIELD, SCRAP, or REWORK). There are other bits of information that can be recorded in this transaction. There are Time Ticket entries which can be logged to record setup times, processing times, and teardown times. Those are the three default activities which can have times recorded. The client has three activities that can also be configured to record other times involved in the operation. If the posting date is in the past, it can be recorded in POSTG_DATE using proper SAP format. In the case of materials having alternate UOM, a specific UOM can be entered. If alternate Work Centers are available, they can be entered here as well. Numerous other opportunities also exist. If there is as desire to record non-category specific information or notes regarding the confirmation, they can be recorded in the CONF_TEXT field.

This example is a very simple one. Confirmations on a client’s system will depend upon their configuration and requirements. They could easily require more information as part of a partial confirmation.

Below see an order, operation, and yield quantity recorded in the Time Tickets section of the BAPI. Once the data is entered, hit F3 (Back) or click on the green ball with the left arrow on the icon menu bar to return to the previous screen. TIMETICKETS should now show 1 entry.



Figure 6 Order, operation, and quantity entered.



With enough information now entered, the BAPI can be executed. Click on the icon of the clock with a green checkmark or hit the F8 key on your keyboard. The result will be:

Figure 7 Saved Confirmation

Note: For complex testing where you have lots of inputs, it is sometimes useful to save the results. Notice that the save icon is displayed. If you click on save, you can save your inputs to the BAPI in the Test Directory and can reuse them when performing future testing. Choose a good description for the comment field so you can remember its usage when returning.



The confirmation is saved to the system but is not yet fully processed in the ERP system. The delay can be a few seconds or sometimes more, depending upon the system and the number of confirmations going through. The confirmation is not only recorded, but does substantial updates throughout the production order space including, costs associated with machine or labor hours, quantities at the confirmation operation’s work center, and updates to expected completion dates and probably many others as well. If there is automatic component consumption, then the associated goods issues will be triggered.

If multiple confirmations occur in a short period of time, there may be conflicts for records of the confirmation or some of the subsequent updates. For testing, waiting 30 seconds between confirmations is usually enough. There is no real impact of running into a locked record, but it can be disconcerting or confusing. It can also cause a developer to waste time solving a non-existent problem. When building an application to perform confirmations, it is sometimes desirable to aggregate a number of confirmation requests together rather than try to run them concurrently (or nearly so)

The Result of the DETAIL_RETURN contains the confirmation number and counter. Write these down for the next phase of testing. The confirmation number is associated with the Order/Operation point and will not change as multiple confirmations are performed. The counter will increment with each confirmation. When reviewing a specific confirmation, both the confirmation number and the associated counter value are required. The Result of the TIMETICKETS will not have the confirmation number displayed despite the first field in the data segment being: CONF_NO.

The confirmation number (CONF_NO) and counter (CONF_CNT) are the last two fields in the DETAIL_RETURN. If the confirmation was saved successfully, these will be populated with non-zero values. Otherwise, CONF_NO will be “0000000000” and CONF_CNT will be “00000000”. Since non-zero values will be present when the confirmation was successfully saved, these two fields can be used programmatically to evaluate the BAPI execution status.

Confirmations in ERP

This step could have just as easily been performed prior to working in the BAPI Explorer. The main issue is to perform confirmations using the ERP system in the standard customer methodology. It is desirable for a person who is familiar with your client’s confirmation process perform a few confirmations upon the sample production order used from BAPI Explorer. Or have such a person provide instructions so that they can be done multiple times during this phase of testing. Record the confirmation numbers and the associated counter values for further testing.

Navigate to the ERP Confirmation screen equivalent of the …CREATE_TT (SAP Transaction Code CO1V):



Figure 8 Navigation to ERP Confirmations



Populate the fields that you are required, again, a minimum of Order, Operation, and a quantity in one of the three quantity fields. You may have to click on Other view button to switch from confirmations by confirmation number to confirmation by order/operation. Once the fields are populated, click on the Enter button (in the upper left the green ball with the check mark). The fields other than those already entered will populate as appropriate. Use the save icon to record the data. You may do more than one confirmation by simply populating multiple lines.

Figure 9 Fast Entry Confirmations

Once the confirmation is saved, it is in a status “Requested Confirmation”. Navigate to Requested Confirmations. (SAP Transaction code C01L)

Figure 10 Requested Confirmations



Enter the order number and, optionally, the operation. If the operation is not entered, the requested confirmations for all operations for that order will be displayed. Click on the Execute icon (clock with green check mark).

Figure 11 Display Requested Confirmations

Figure 12 Requested Confirmations

Highlight the row with the (Confirmation) Number and Counter of interest by putting your mouse pointer on the block to the left of the record and clicking. The row will highlight. To force completion of the confirmation request, click on the execute button labeled Confirm. The selected confirmation request(s) will be processed and the highlighted records will disappear.

To view the confirmations that have been processed, go to Display Confirmations (SAP Transaction Code CO14). Enter the Order number and optionally the operation and hit enter or click the enter icon. A list of completed confirmations will be displayed. Compare the confirmations done in BAPI Explorer to those performed in ERP. Determine what the differences are and what fields need to be populated in BAPI Explorer to have the end results be the same. As the checkboxes would indicate, you can select one or more confirmations to compare and then toggle through them as desired.



Figure 13 Completed Confirmation List

Figure 14 Completed Confirmation Details



Confirmations via MII

Within MII, a few simple transactions are all that is needed to determine the required inputs and formats for the BAPI to execute in an identical manner to how they execute within the ERP system. Start with the BAPI_PRODORDCONF_CREATE_TT as was done within BAPI Explorer. Create the transaction shown above and link the Response segment of the JCo Interface action block to the Message property of the Tracer. Configure the JCo Interface to use the SAP Alias created earlier. Type in the …TT BAPI name or use a search pattern to select it into the RFC Name text box. Make sure Execute Transaction is checked and Automatically Commit Transaction is unchecked (for now). This is not a Best Practices design. This is a simple testing tool for determining proper BAPI inputs to correctly perform production order confirmations in SAP MII.

Over on the Link Editor side, update the fields as needed. Our simple example is again only populating Order, Operation, and the Yield fields. Your requirements may require more links.

Notice in the screen print of the Link Editor window, that the Order is “000001006323” rather than “1006323” as was used in both BAPI Explorer and in the various ERP transactions. In BAPI Explorer as well as the ERP transactions formatting of the order number occurs prior to it being processed. The BAPI being access from the JCo Interface action block does not have such pre-processing functionality. So to process an order



number, it must be properly formatted. There are several different ways of formatting it, but here are two simple expressions which will set your order number in the correct format.

format(Transaction.OrderNumber, "000000000000")

stringright(“000000000000”&Transaction.OrderNumber, 12)

Note: This pertains to clients that use standard SAP order number formats and do not mix in alphabetic characters. Formatting is also required for Material numbers, Batch numbers, Inspection Lot numbers, etc. The length of the number is usually able to be found by populating the field in BAPI Explorer. They are sized appropriately and exactly. You can also look up the schema, but BAPI Explorer is often easier to find.

Multiple confirmations can be performed in a single BAPI call. Simply add additional item segments to the TIMETICKETS segment prior to executing the transaction. The technical aspects of performing multiple confirmations will not be addressed here. SDN does have some good posts and blogs that address the issue.

Once the links have been populated, close the editor and, optionally, save the transaction. Execute the transaction. Since the Automatically Commit Transaction is unchecked, the transaction will be executed and then rolled back. This allows testing of the parameters prior to full testing. Once the transaction has been successfully executed, the box should be checked. Then run the transaction again to perform a full test.



This time record the confirmation number and confirmation counter from the response segment (in the Tracer). Save the current transaction as a new name (DisplayConfirmations, perhaps?). Change the BAPI to BAPI_PRODORDCONF_GETDETAIL. Remove all the previous links and use the confirmation number and counter to the appropriate INPUT fields. Then execute. Save the response segment in an xml file. Do the same with the confirmations performed in the ERP system. Then compare each field in the response segment from both sources (MII and ERP). Make note of what the differences are. These differences will usually indicate that additional links are required in your BAPI call. Add additional links until there are no (significant) differences between the two confirmations.




Copyright © 2008 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, System i, System i5, System p, System p5, System x, System z, System z9, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, POWER5+, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

MaxDB is a trademark of MySQL AB, Sweden.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

These materials are provided “as is” without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.

SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials.

SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages.

Any software coding and/or code lines/strings (“Code”) included in this documentation are only examples and are not intended to be used in a productive system environment. The Code is only intended better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, except if such damages were caused by SAP intentionally or grossly negligent.

tips and tricks for building erp interfaces in mii · pdf filetips and tricks for building erp...

Documents