Complete Interface Management Using ECS

Texas Barcode Systems 6504 International Pkwy. Suite 1500 Plano, TX 75093 www.texasbarcode.com (p) 972.267.7900 (f) 972.267.
7901 Toll Free: 888.812.7226
Complete Interface Management for SAP R/3

There are hidden costs associated with poor interfacing. The ECS interface management framework provides the total visibility and fundamental management controls necessary to ensure integrity and minimise downtime.
Empower business users Reduce development and support costs by as much as 60% Streamline processing
Page 1 of 24 Version 1.1
Texas Barcode Systems 6504 International Pkwy. Suite 1500 Plano, TX 75093 www.texasbarcode.com (p) 972.267.7900 (f) 972.267.7901 Toll Free: 888.812.7226
1 2 3
PREFACE ..............................................................................................................................................3 EXECUTIVE SUMMARY ...................................................................................................................4 THE FUNDAMENTAL REQUIREMENTS OF GOOD INTERFACING......................................6 3.1 3.2 3.3 3.4 3.5 DATA INTEGRITY ..............................................................................................................................6 TRACEABILITY, ORGANIZATION AND SECURITY ...............................................................................7 PROACTIVE MONITORING, AUTOMATIC NOTIFICATION AND STATISTICS ...........................................7 CHECKPOINT RESTART .....................................................................................................................8 DEPENDENCY CONTROLS AND SCHEDULING .....................................................................................8 NO STANDARD FRAMEWORK FOR INTERFACING ...............................................................................9 LACK OF DEPENDENCY CONTROLS ...................................................................................................9 LACK OF TRACEABILITY AND LOGGING MECHANISMS ....................................................................10 NO SINGLE POINT TO MONITOR AND MANAGE ALL PROCESSING .....................................................10 LACK OF COMMON PROVEN UTILITIES ............................................................................................11 NO HIGH VOLUME PERFORMANCE MANAGEMENT ...........................................................................12 NO SIMPLE CONDITIONAL PROCESSING LOGIC ................................................................................12 NO CHECKPOINT RESTART CAPABILITY ..........................................................................................12 INADEQUATE SCHEDULING CAPABILITY .........................................................................................13 NO ABILITY TO PERFORM LOW LEVEL MONITORING OF OUTPUT OR LOGS .......................................13 NO BUILT-IN DOCUMENTATION AND ANNOTATION FACILITIES .......................................................13
WHAT R/3 DOES NOT PROVIDE.....................................................................................................9 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11
5 6
THE HIDDEN COSTS OF POOR INTERFACES ..........................................................................14 HOW ECS PROVIDES COMPLETE INTERFACE MANAGEMENT........................................15 6.1 NOTIFICATION ................................................................................................................................15 6.2 MONITORING ..................................................................................................................................16 6.2.1 Monitoring the overall status of interfaces............................................................................16 6.2.2 Monitoring individual runs....................................................................................................17 6.3 THE ECS ONLINE WORKBENCH ......................................................................................................18 6.4 STATISTICS .....................................................................................................................................19 6.5 DEPENDENCY AND SCHEDULING CONTROLS ...................................................................................20 6.6 RESTART RECOVERY ......................................................................................................................21 6.7 ANNOTATION/DOCUMENTATION ....................................................................................................22 6.8 AUTOMATION .................................................................................................................................23
APPENDIX ..........................................................................................................................................24 7.1 7.2 CONTACTING TEXAS BARCODE ......................................................................................................24 SAP R/3 WHITE PAPERS ..................................................................................................................24
Page 2 of 24
Version 1.1
1 Preface
The interfacing techniques mentioned in this paper are not unique to SAP R/3. Like many things in computing, the fundamentals have not changed since the days of mainframe processing. In fact the whole concept of the Event Control System (ECS) software was to compliment the SAP R/3 system by addressing much-needed gaps in interface management. Many managers are surprised that R/3 does not provide better facilities for managing interfaces. The fact is, whilst R/3 provides an excellent integrated business solution and many mechanisms for interfacing with external systems, it does not provide a consistent integrated technical framework for managing interfaces end-to-end. Subsequently, programmers expend large amounts of effort to address all those what if scenarios. Even worse, some are not even aware, or dont bother to build in the essential controls to guarantee data integrity, traceability, notification, restart/recovery etc. It seems that with every new technology, the same lessons are learnt over and over again. It is only those few, which have been already been through the mill, that pro-actively look to build the necessary safeguards and monitoring into the design. Five years ago when Sky first started integrating external systems and devices with SAP R/3, it became very obvious that there was no central monitoring system and no mechanism to logically link all the technical steps of an interface together. ECS was borne. Since then, the system has grown over the years to become a powerful effective interface management framework that has proven its worth time and time again! This white paper explores the necessity for an interface management framework and the hidden costs associated with poor interfacing techniques in R/3. This paper is the expressed opinion of Sky Technologies Pty Ltd of Australia and is intended to inform SAP R/3 customers of best practise interface management techniques with SAP R/3.
Page 3 of 24
Version 1.1
2 Executive summary
Whilst SAP R/3 provides an excellent integrated business solution and many good mechanisms for interfacing with external systems and data, it does not provide a robust, consistent integrated technical framework for managing interfaces in the R/3 environment. IT and business users need be pro-actively notified of any problems, and have the ability to monitor all interface executions from a single point, and reprocess failures in a controlled fashion. The emphasis here is on interface management in SAP and not external middleware or EAI solutions. Standard SAP R/3 does not provide: A standard sub-system to define interfaces and their characteristics A single point from which to proactively monitor and manage all interfaces Effective dependency controls to dictate the order of processing Adequate data tracking and logging mechanisms A high volume performance management system An automatic notification and escalation facility Standard utility objects e.g. external file management and polling Advanced multi-level scheduling capability Online documentation and annotation facilities Checkpoint restart of failed interface runs.
There are hidden costs associated with poor interfacing: High maintenance and support cost. Predominantly Business and IT manpower Loss of credibility with external Suppliers/Customers Financial cost due to data loss, corruption, duplication etc. High development and upgrade cost due to inconsistency and having to provide the supporting architecture as well as the business solution.
Middleware is just another interface to be managed! The above holds true with the majority of, if not all, middleware solutions. Middleware, whilst offering good translation and brokering services, is essentially an interface to R/3 itself. Most wash their hands of transactions once they have been successfully submitted to R/3, thus customers are usually left struggling with the inadequate interface management facilities and the general unknowingness of what is happening in R/3.
Page 4 of 24
Version 1.1
ECS is proven technology that provides a solution Sky Technologies has developed the Event Control System (ECS) to specifically address the lack of interface management capability in R/3. Toyota, Nissan, Visy Industries, Southcorp are just a few of the companies that totally rely on ECS to successfully manage their SAP interfacing and business scheduling. ECS has been in use in a production sense for over four years and is industry strength, handling thousands of transactions every day. The product is not only used in Australia, but in the US, UK, Malaysia and Indonesia. ECS actually runs in SAP R/3 and has the same look and feel as a SAP application, thus there is no need to incorporate another set of skills and the administration overhead that an external system incurs. The cost benefit Usually its hard to convince new SAP R/3 customers that they need to effectively manage interfacing. It is often seen as a lesser task in the scheme of things. But post go live, the same customers almost always regret not doing it better, and usually lack the budget, skills or inclination to fix it. Much time and materials is lost without the benefit of hindsight. However, it is a relatively simple exercise to measure the cost of finding and fixing and offset this against the cost of implementing a good management framework i.e. the return on investment (ROI). Sky has benchmarked this cost and has found on average that by implementing ECS, Customers have saved over 60% in measurable support and development costs, as well as intangible benefits such as regained credibility with external Suppliers and Customers. ECS is a low cost solution, starting at $10K USD. In most cases this outlay has been recouped within six months of implementation. ECS is designed specifically for R/3 and runs in the R/3 environment, thus existing SAP skills may be utilised to convert existing interfaces and develop new ones, without having to employ specialist consultants. Keeping it simple There is nothing wrong with using the right tool for the job and the same principle applies to interfacing. In SAP R/3 there are many different mechanisms available and all have their pros and cons. There is nothing wrong with using basic fixed record file transfer instead of XML, or a BDC instead of an IDOC, if there are justifiable reasons for doing so. Often, the IT architects vision of a centralised all things to all interfaces transaction broker becomes over complex, costly to implement and requires a high degree of specialist skill to maintain and operate. If the Customer is SAP centric, then direct interfacing to external systems should be used wherever possible without any middleware. The more layers, the more points of failure, and the more management required!
Page 5 of 24
Version 1.1
3 The fundamental requirements of good interfacing

The overall primary goal of any interface is to transmit data between one or more applications without losing the context and value of the data. However, by nature, interfaces nearly always have multiple technical steps and each step is a potential point of failure. Generally, the more steps there are, the higher the probability of failure and the higher the effort to develop and support the interface. This is true, no matter what the technology, method or standard being used e.g. file transfer, XML, peer-to-peer sockets, Object Oriented etc. Programmers need to address all the what if scenarios e.g. How do I know that all the data has been transmitted/received? How will a problem be detected? How will support staff know that the interface has failed? What if an unexpected failure occurs at this point How will the interface be restarted again? How can I be assured that the interfaces will execute in the correct order?
3.1 Data integrity

Controls must be put in place that all data is correctly transmitted and received between two points. The receiving interface must not start processing until all the data is received and is accounted for. For example: A customer had the problem where occasionally, not all the transactions in a file were received in SAP R/3. The file had been transmitted to the SAP R/3 host, had been picked up by a polling mechanism and the ABAP interface program had been triggered to process the file. It turned out that in some cases, the interface was triggered prematurely i.e. whilst the file was still being sent. This is a common problem when using FTP with large files. There were no mechanisms in place to detect that the file was still growing, or controls in the data to ensure that all the data is there. The result was loss of data and a corrupt business process!
Page 6 of 24
Version 1.1
3.2 Traceability, organization and security

Each execution of an interface should be uniquely identified (e.g. run number). Each technical step within the interface run should be clearly identified and executed in sequence. The overall interface run and its technical steps should be classified in business terms e.g. Sales Order 516719, Material 100003689 etc. In addition, runs of a particular interface may need to be grouped together into an area that is responsible for them e.g. by SAP Plant. This may also be essential for security. You need to be able to: Uniquely identify each interface run Identify each step within an interface run Classify what the interface run means in business terms Annotate each step of the interface run to provide meaningful processing information for support, audit etc. List all resources used by each interface step e.g. files, parameters, BDC sessions, IDOCs etc. Log all actions performed against the interface run e.g. when it started, when it was reprocessed, when it failed, who fixed it, when it finished etc. Logically group interface runs together for a particular responsibility area. Secure interface runs to be viewed and managed by particular roles.
3.3 Proactive monitoring, automatic notification and statistics

An essential part of interface management is for both Business and IT staff to easily view all the interface runs from a single point in R/3. They should be able to drill down on failed runs and diagnose the cause. The interface framework should also promote proactive monitoring by automatically notifying nominated users of any problems. This can be achieved by email, SMS or via an external monitoring/paging system. Trend analysis is important to view how many runs are being executes, peak processing, total failures, the amount of time taken to fix problems etc. You need to be able to: View the overall status of all interfaces Drill down on interface runs to view the technical steps Automatically notify nominated support staff when a problem occurs (e.g. Email) View statistics of total runs, failures, time taken to fix failures etc.
Version 1.1
Page 7 of 24
3.4 Checkpoint restart

If an error occurs, the interface should be able to be restarted from the point of failure. In addition a clear distinction needs to be made between technical and business errors and controls are necessary to enable automatic restart or if the interface can be restarted and by whom. For example: If an error was detected on record 900 of a 2000 transaction file, support staff should be able to rectify the data and start again from record 900.
3.5 Dependency controls and scheduling

Dependency controls manage the sequence in which interfaces are executed. This becomes important if interfaces cannot execute at the same time, or must be executed in a particular order. Scheduling is the ability to plan the interface run into the future or release it when a specific event occurs. For example: R/3 only allows one material movement to occur at any one time for a specific plant/material combination. If more than one is processed at a time, the others are locked out and are failed. A warehouse management system may submit hundreds or thousands of material movements per day to R/3. These need to be serialised by plant and material to only allow one of each to execute at a time or else unnecessary failures will occur. You need to be able to: Execute the steps of an interface in a specific order Only allow one run of a interface to execute at a time Logically lock an entire run, or a specific step of an interface. Any other runs are suspended until execution ends (or is successfully completed). Suspend processing of an interface for manual user confirmation Schedule interface runs (or a specific step) to run at a specific date, time or event Delay execution of all interfaces until a time in the future (e.g. downtime window) Ignore or fail processing if the interface has already run
Page 8 of 24
Version 1.1
4 What R/3 does not provide

Although R/3 provides many mechanisms for interfacing (BDC, IDOC, BAPI etc.) and all the low level functionality to handle processing, it is open ended with no supporting framework and consistent mechanism for implementing good interfaces. Much is left up to the developer who needs not only to implement the business logic, but also the technical harness to monitor and reprocess failures. The result is that each developer (usually a contractor) implements their own flavour and the customer is left with many different interface techniques and systems.
4.1 No standard framework for interfacing

R/3 does not have a standard framework to manage and control interfacing. The result is that developers need to spend as much time addressing the technical support aspects, as they do implementing the business logic. A standard framework should provide all the monitoring, flow and dependency controls necessary, allowing the developer to concentrate only on the code to implement the business logic, messages etc. In addition, many common routines for processing transactions, logging and passing data between steps can be reused time and time again. Sky has benchmarked that Customers will save as much as 60% development and testing time by having a consistent interface framework in place.
4.2 Lack of dependency controls

Dependency controls allow developers to implement proper sequencing e.g. only allow one run at a time for a specific plant/material combination to avoid failure due to locked resources in R/3. Serialisation and logical locking allow interface runs to execute in a specific order, thus ensuring transaction integrity and avoiding resource-locking failures. Whilst R/3 does provide some rudimentary serialisation for some things (e.g. IDOCs), it is rarely adequate and is administration intensive. At a minimum, you need to be able to: Sequence processing in a particular order Serialise the processing of interface runs (one at a time) Provide logical locking mechanisms across all interfaces Delay processing until a particular time or event Suspend further processing if a error occurs
Version 1.1
Page 9 of 24
4.3 Lack of traceability and logging mechanisms

It is nearly always necessary to audit the process of an interface i.e. provide information on the success and failure of each step. R/3 provides no standard functionality to do this. In addition, interface runs should be classified in business and not technical terms. For example: If a business user wanted to find out what happened to a particular sales order created from another system, they should be able to easily find the interface run that created it. Typically, the interface runs and their objects (files, BDC, IDOC etc.) are referenced by a unique technical number and there is no cross reference with these to business data. You need to be able to: Uniquely identify each interface run Logically group all steps of an interface run Annotate each step of a run Classify the interface run in business terms Provide links to all job logs, spool, short dumps etc. associated with the run
4.4 No single point to monitor and manage all processing

Interfaces usually consist of multiple steps that execute different objects in different modes. There is no central point in SAP R/3 to view all the components of an interface. For example: A typical interfacing technique is: 1. 2. 3. 4. 5. The SAP system receives a file The file is detected in the inbound directory and moved to a processing directory A job is triggered in SAP to execute a ABAP program to generate a BDC session The file is moved to the archive directory The BDC session is submitted for execution
In this simple example, there are five distinct technical steps that constitute a single interface run. R/3 provides no standard mechanism to logically group all the steps together and no central point to monitor it as such. Developers often resort to crude progress/status tables, which are updated along the way.
4.5 Lack of common proven utilities

R/3 does provide most of all the mechanisms to perform interfacing e.g. File processing commands Ability to execute external commands to copy, move, rename, delete files etc. Ability to trigger background processing (Jobs, asynchronous function calls etc.) BDC processing commands IDOC processing commands Function calls (BAPI, system functions etc.)
However, these are low level and the developer must implement the correct error processing and call options to ensure they are robust and upgradeable. R/3 does not provide standard proven common routines and utilities that may be reused time and time again i.e. the developer just plugs in the utility function, knowing it works. Many common functions should be provided by the interface framework and made configurable i.e. no code required. This saves considerable development, testing and support time, because the utilities are standard and are known to work with correct error handling. For example: In the typical interfacing scenario: 1. 2. 3. 4. 5. The SAP system receives a file The file is detected in the inbound directory and moved to a processing directory A job is triggered in SAP to execute a ABAP program to generate a BDC session The file is moved to the archive directory The BDC session is submitted for execution
The interface framework should handle all the steps (1,2,3,4,5) automatically. The developer need only provide the ABAP program to execute. In addition, the standard framework provides all the sequencing, documentation and logging mechanisms that would otherwise have to be developed.
Page 11 of 24
Version 1.1
4.6 No high volume performance management

In cases where large volumes of interface runs are submitted asynchronously into SAP R/3, Customers may encounter severe performance problems with the background job, asynchronous transaction and/or IDOC sub-systems. There are no controls to limit or zone this processing to only use limited resources of the SAP system, thus flooding can occur where all processes are consumed and SAP performance is affected. In addition, there is processing and wait overhead associated with these R/3 background sub-systems that can become excessive for high frequency short sharp transactions. For example: A high volume production line issues production order confirmations (CO11) transactions as it consumes raw materials. These are detected and issued to SAP using an automated barcode system. The result is a CO11 transaction being issued to SAP every second. Customers usually address these types of problems by purchasing dedicated hardware (a expensive proposition!). An interface framework should be able to accept these transactions and queue them to be processed in a continuous cycle i.e. a controlled number of dedicated batch jobs feeding off a central transaction queue. In this way, the R/3 scheduling overhead is avoided, twice as many transactions can be processed and the effect on the rest of the system is minimised.
4.7 No simple conditional processing logic

R/3 has no simple conditional processing mechanism. The only standard way to address this is to use SAP workflow, which is complex, slow and expensive (both in cost and system resource). Conditional logic provides the ability to optionally execute parts of the interface, depending on the data received. It enables modular solutions that may be shared between different interfaces.
4.8 No checkpoint restart capability

SAP R/3 does not provide standard mechanism to restart processing from the point of failure. Some individual interface mechanisms e.g. BDC processing does have inherent logical units of work, but there is no general ability to checkpoint a phase within a interface run as complete, or a specific point within data processing, so that if the interface run was restarted it would not duplicate transactions.
4.9 Inadequate scheduling capability

R/3 has a rudimentary scheduling system. Interfaces may need to delay or cancel processing under certain circumstances. R/3 does not provide adequate scheduling functionality for most of these scenarios. For example: Ignore/fail processing if the interface has already run today Run the interface every hour between the hours of 8am to 6pm, Monday to Friday Release interface C, once interfaces A and B have completed successfully Only run the interface on the following R/3 instances and only ever utilise a maximum of three background processes Trigger the interface from a SAP update task (e.g. user exit)
4.10 No ability to perform low level monitoring of output or logs

Many standard SAP interface programs do not fail when they encounter problems. Instead, they list the problems to the spool or job log. Business users must then manually check these messages, before allowing the interface, or subsequent interfaces, to continue. This can waste valuable processing and people time. In order to automate these interfaces, programmers must write code to scan the logs and/or spool for error conditions. An interface framework should provide the ability to configure this low level of monitoring and the actions to take e.g. fail the run if the following message was/was not received.
4.11 No built-in documentation and annotation facilities

Because interfaces are usually made up of multiple technical steps and may require specific instructions to restart them if they fail, it is important that support staff has this documentation at hand to quickly resolve a problem. It is also important to annotate the actions taken to resolve a problem for future reference. Printed materials get quickly out of date and may not be available, when the problem occurs. An interface framework should provide facilities to document the interface and its steps; it should also provide a standard mechanism to annotate interface failures with comments.
5 The hidden costs of poor interfaces

It is sometimes very difficult for managers to detect how much time is wasted in supporting failed interfaces and the overall impact they have on the business. Often SAP customers will maintain the status quo after an implementation (i.e. thats the way it is!) and fire fight problems as they arise. However, expending a little time to analyse these hidden costs can reap large rewards in saved manpower and business downtime. You need to ask the following questions of each interface: How often does it fail? How do we know it failed? How long is it before we know it failed? What is the business impact if it does not run? How much time is spent finding and fixing?
Once you have these figures, you can then calculate the savings, if: Support staff are: o Notified immediately a failure occurred o Know exactly where the interface failed and why o Have the ability to automatically reprocess from the point of failure Business users are empowered to monitor (possibly manage) their own interfaces o Less reliance on IT o Less delay Recurring technical problems were eliminated through the use of a robust interface framework
For example: A company implemented an EDI interface with a financial institution to approve and process hire purchase agreements. The interface failed from time to time and went undetected, until customers complained. The business then contacted the IT department, which then started manually tracing the transactions through the EDI interface. For each failure, an entire man-day of effort was expended by the business and IT to find and correctly resolve the customers problem. The problem was occurring at least twice a week. The impact of this interface was 96 support days a year, lost credibility with customers and high administration fees with the financial institution.
Page 14 of 24
Version 1.1
6 How ECS provides complete interface management

The Event Control System (ECS) is an interface management framework developed by Sky Technologies specifically for SAP R/3 interfacing. ECS provides comprehensive functionality to monitor and control the execution of interfaces between external systems and SAP R/3. The following diagram depicts the main services provided by the ECS framework:
6.1 Notification
ECS automatically notifies support staff of any failures. This can be implemented in a variety of ways: Exception reporting Email (SMS) External notification system or paging service (e.g. HP-Open view, CAUnicenter)
This monitoring system promotes pro-active support, thus minimizing business downtime. ECS also provides an automatic escalation system that notifies the secondary contact, should the primary contact not respond in a given time frame.
Page 15 of 24
Version 1.1
6.2 Monitoring
A real-time monitoring system is available, in SAP R/3, which provides information on all interfaces. Support staff can view the status of all, or specific interfaces, and can easily drill down on problem areas. The following are just a few samples of the many transactions available. 6.2.1 Monitoring the overall status of interfaces The following example screen shot shows an interface summary in R/3. The user can drill down on any specific interface by double clicking or selecting a hotspot on a specific line or field. In ECS terminology, an interface is known as a Process and each step is known as a Phase. SAP security may be implemented, so that users or specific roles can only view certain interfaces or groups of interfaces.
Page 16 of 24
Version 1.1
6.2.2 Monitoring individual runs The following screen shot is a breakdown of a specific interface run, showing the individual technical steps. Failed runs may be reprocessed or force completed from this point. Each high level entry is a unique run of the interface, the next level down displays the steps that have been executed and/or re-processed.
From this central point, users can view all the details associated with an interface run, e.g.

The steps (Phases) executed to date The job logs, BDC sessions, IDOCs, files etc. The dependencies i.e. locks, sequencing, scheduling etc. Documentation and annotation logs
Users can also restart, cancel or force complete runs. SAP security can be implemented for any of these options against specific users or roles.
Page 17 of 24
Version 1.1
6.3 The ECS online workbench

The ECS online workbench is where Interface definitions and all the rules for processing are configured. It is available directly in SAP R/3.
Using the workbench, developers can: Configure the Interface definition Test the interface definition Transport the interface definition across SAP systems Document the interface definition Configure the dependency and housekeeping rules Configure automatic notification rules Configure conditional processing
Page 18 of 24
Version 1.1
6.4 Statistics
ECS keeps run time statistics on all interface runs i.e. started runs, clean runs, failures etc. The statistics manager may be used to list these statistics using multiple views, or they may be downloaded to the PC for analysis.
Using these statistics, effective trend analysis can be performed to quickly identify hot spots, bottlenecks in processing or the effectiveness of changes. KPI (key performance indicators) can also be checked to see how quickly failures were resolved.
Page 19 of 24
Version 1.1
6.5 Dependency and scheduling controls

ECS has comprehensive dependency controls and scheduling capability. These are often implemented as standard configuration using the ECS workbench, but also may be defined at run time within ABAP programs using the ECS SDK (software developers kit). The following table lists some of the options available: Logical locking Sequencing Only process one run at a time (serialization) Ignore starting if an instance is already running Enqueue the entire run and/or a specific Phase (step) based on a value e.g. plant/material Only release the enqueue when the run/phase is successful Lock on a combination of values e.g. material and purchase order Suspend the run, waiting for manual user confirmation First in first out (as started) By user specified sequence number Specify a priority Abort if run within hh:mm:ss of previous run Automatically reprocess failures under the specified conditions (too many to mention here!) Run at a specific date/time (or any scheduling option e.g. first/last day of the month) Configure scheduling exceptions e.g. only Monday to Friday between the hours of 8am to 6pm. Only run the interface on certain SAP instances, utilizing a maximum of xxx background processes
Scheduling
It is important to note that ECS can also be used for other processing in the SAP system as well as interfacing e.g. month end scheduling.
Page 20 of 24
Version 1.1
6.6 Restart recovery

Failure and reprocessing rules may be configured using the ECS workbench. This enables failed interface runs to be restarted in a controlled manner. You may also prevent reprocessing under certain conditions or instruct ECS to automatically restart after a failure e.g. try x times waiting x seconds in-between.
The run detail screen highlights failed runs and the Phase (step) that the error occurred on. Support staff may then investigate or simply execute the reprocess button. Runs may also be undone back to a specific point. In the above example, ECS has detected that BDC processing has failed. Support staff may view the BDC log, instruct ECS to execute the BDC again or re-process the BDC online.
Page 21 of 24
Version 1.1
6.7 Annotation/documentation
ECS provides the facility to document Interfaces and their steps online in a number of ways. In this way, the documentation is kept up to date and is readily accessible to all support staff. In addition, any run or specific step of a run may be annotated to keep track of events and actions taken. The following options are available: Online documentation using a PC editor of choice e.g. Microsoft Word Online documentation using simple text notes Annotation of runs either manually or programmatically
ECS automatically annotates Interface runs where it can, for example: Failures (automatic extract and diagnosis of logs, short dumps etc.) File, BDC, IDOC, ABAP processing
Page 22 of 24
Version 1.1
6.8 Automation
ECS provides many facilities to completely automate interface processing. For example: Poll directory definitions may be configured to automatically scan a nominated directory for a specified file name (or wild card) and automatically start an Interface when the file has been successfully received (i.e. finished growing).
Files may be automatically copied, moved, renamed or deleted as part of the Interface definition, by simply configuring options in the workbench. This saves considerable development and testing time.
Page 23 of 24
Version 1.1
7 Appendix
7.1 Contacting Sky
6504 International Pkwy. Suite 1500 Plano, TX 75093 www.texasbarcode.com (p) 972.267.7900 (f) 972.267.7901 Toll Free: 888.812.7226
7.2 SAP R/3 white papers

The following white papers are available on request from Texas Barcode Systems: The VTI Mobile Business Framework Seamless Application Integration Advanced Business Scheduling Machinery/Device Integration EFT/POS Integration Complete Interface Management Java .net Object Oriented Integration File based Interfacing The Cupid Data Translator
Page 24 of 24
Version 1.1

Complete Interface Management Using ECS

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Complete Interface Management Using ECS

Uploaded by

Copyright:

Available Formats

Texas Barcode Systems 6504 International Pkwy. Suite 1500 Plano, TX 75093 www.texasbarcode.com (p) 972.267.7900 (f) 972.267.

7901 Toll Free: 888.812.7226

Complete Interface Management for SAP R/3

3 The fundamental requirements of good interfacing

3.1 Data integrity

3.2 Traceability, organization and security

3.3 Proactive monitoring, automatic notification and statistics

3.4 Checkpoint restart

3.5 Dependency controls and scheduling

4 What R/3 does not provide

4.1 No standard framework for interfacing

4.2 Lack of dependency controls

4.3 Lack of traceability and logging mechanisms

4.4 No single point to monitor and manage all processing

4.5 Lack of common proven utilities

4.6 No high volume performance management

4.7 No simple conditional processing logic

4.8 No checkpoint restart capability

4.9 Inadequate scheduling capability

4.10 No ability to perform low level monitoring of output or logs

4.11 No built-in documentation and annotation facilities

5 The hidden costs of poor interfaces

6 How ECS provides complete interface management

6.3 The ECS online workbench

6.5 Dependency and scheduling controls

6.6 Restart recovery

7.2 SAP R/3 white papers

You might also like