Complete Interface Management Using ECS

8/3/2019 Complete Interface Management Using ECS

1/24

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

Complete

Interface

Managementfor

SAP R/3

There are hidden costs associated with poor interfacing.The ECS interface management framework provides thetotal visibility and fundamental management controlsnecessary to ensure integrity and minimise downtime.

Empower business users

Reduce development and support costs by as much as60%

Streamline processing


2/24





(p) 972.267.7900 (f) 972.267.7901

Toll Free: 888.812.7226

1 PREFACE..............................................................................................................................................3

2 EXECUTIVE SUMMARY ...................................................................................................................4

3 THE FUNDAMENTAL REQUIREMENTS OF GOOD INTERFACING......................................6

3.1 DATA INTEGRITY ..............................................................................................................................63.2 TRACEABILITY, ORGANIZATION AND SECURITY ...............................................................................73.3 PROACTIVE MONITORING, AUTOMATIC NOTIFICATION AND STATISTICS ...........................................73.4 CHECKPOINT RESTART .....................................................................................................................83.5 DEPENDENCY CONTROLS AND SCHEDULING .....................................................................................8

4 WHAT R/3 DOES NOT PROVIDE.....................................................................................................9

4.1 NO STANDARD FRAMEWORK FOR INTERFACING ...............................................................................94.2 LACK OF DEPENDENCY CONTROLS ...................................................................................................94.3 LACK OF TRACEABILITY AND LOGGING MECHANISMS ....................................................................104.4 NO SINGLE POINT TO MONITOR AND MANAGE ALL PROCESSING .....................................................104.5 LACK OF COMMON PROVEN UTILITIES ............................................................................................114.6 NO HIGH VOLUME PERFORMANCE MANAGEMENT ...........................................................................124.7 NO SIMPLE CONDITIONAL PROCESSING LOGIC ................................................................................124.8 NO CHECKPOINT RESTART CAPABILITY ..........................................................................................124.9 INADEQUATE SCHEDULING CAPABILITY .........................................................................................134.10 NO ABILITY TO PERFORM LOW LEVEL MONITORING OF OUTPUT OR LOGS .......................................134.11 NO BUILT-IN DOCUMENTATION AND ANNOTATION FACILITIES .......................................................13

5 THE HIDDEN COSTS OF POOR INTERFACES ..........................................................................14

6 HOW ECS PROVIDES COMPLETE INTERFACE MANAGEMENT........................................15

6.1 NOTIFICATION ................................................................................................................................156.2 MONITORING..................................................................................................................................16

6.2.1 Monitoring the overall status of interfaces............................................................................166.2.2 Monitoring individual runs....................................................................................................17

6.3 THE ECS ONLINE WORKBENCH ......................................................................................................186.4 STATISTICS.....................................................................................................................................196.5 DEPENDENCY AND SCHEDULING CONTROLS ...................................................................................206.6 RESTART RECOVERY ......................................................................................................................216.7 ANNOTATION/DOCUMENTATION ....................................................................................................226.8 AUTOMATION.................................................................................................................................23

7 APPENDIX ..........................................................................................................................................24

7.1 CONTACTING TEXAS BARCODE......................................................................................................24

7.2 SAPR/3 WHITE PAPERS..................................................................................................................24


3/24





(p) 972.267.7900 (f) 972.267.7901

Toll Free: 888.812.7226

1 Preface

The interfacing techniques mentioned in this paper are not unique to SAP R/3. Like manythings in computing, the fundamentals have not changed since the days of mainframeprocessing. In fact the whole concept of the Event Control System (ECS) software was tocompliment the SAP R/3 system by addressing much-needed gaps in interfacemanagement.

Many managers are surprised that R/3 does not provide better facilities for managinginterfaces. The fact is, whilst R/3 provides an excellent integrated business solution andmany 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 toguarantee data integrity, traceability, notification, restart/recovery etc. It seems that withevery new technology, the same lessons are learnt over and over again. It is only thosefew, which have been already been through the mill, that pro-actively look to build thenecessary safeguards and monitoring into the design.

Five years ago when Sky first started integrating external systems and devices with SAPR/3, it became very obvious that there was no central monitoring system and nomechanism 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 effectiveinterface management framework that has proven its worth time and time again!

This white paper explores the necessity for an interface management framework and thehidden costs associated with poor interfacing techniques in R/3. This paper is theexpressed opinion of Sky Technologies Pty Ltd of Australia and is intended to informSAP R/3 customers of best practise interface management techniques with SAP R/3.


4/24





(p) 972.267.7900 (f) 972.267.7901

Toll Free: 888.812.7226

2 Executive summary

Whilst SAP R/3 provides an excellent integrated business solution and many goodmechanisms for interfacing with external systems and data, it does not provide a robust,consistent integrated technical framework for managing interfaces in the R/3environment. IT and business users need be pro-actively notified of any problems, andhave the ability to monitor all interface executions from a single point, and reprocessfailures in a controlled fashion. The emphasis here is on interface management in SAPand 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 providethe 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/3itself. Most wash their hands of transactions once they have been successfullysubmitted to R/3, thus customers are usually left struggling with the inadequate interfacemanagement facilities and the general unknowingness of what is happening in R/3.


5/24





(p) 972.267.7900 (f) 972.267.7901

Toll Free: 888.812.7226

ECS is proven technology that provides a solution

Sky Technologies has developed the Event Control System (ECS) to specifically addressthe 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 successfullymanage their SAP interfacing and business scheduling. ECS has been in use in aproduction sense for over four years and is industry strength, handling thousands oftransactions 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 asa SAP application, thus there is no need to incorporate another set of skills and theadministration overhead that an external system incurs.

The cost benefit

Usually its hard to convince new SAP R/3 customers that they need to effectivelymanage interfacing. It is often seen as a lesser task in the scheme of things. But post golive, the same customers almost always regret not doing it better, and usually lack thebudget, skills or inclination to fix it. Much time and materials is lost without the benefitof hindsight. However, it is a relatively simple exercise to measure the cost of findingand fixing and offset this against the cost of implementing a good managementframework i.e. the return on investment (ROI). Sky has benchmarked this cost and hasfound on average that by implementing ECS, Customers have saved over 60% inmeasurable 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 ofimplementation. 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 newones, 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 appliesto interfacing. In SAP R/3 there are many different mechanisms available and all havetheir pros and cons. There is nothing wrong with using basic fixed record file transferinstead of XML, or a BDC instead of an IDOC, if there are justifiable reasons for doingso. Often, the IT architects vision of a centralised all things to all interfaces transactionbroker becomes over complex, costly to implement and requires a high degree ofspecialist skill to maintain and operate. If the Customer is SAP centric, then directinterfacing to external systems should be used wherever possible without anymiddleware. The more layers, the more points of failure, and the more managementrequired!


6/24





(p) 972.267.7900 (f) 972.267.7901

Toll Free: 888.812.7226

3 The fundamental requirements of good interfacing

The overall primary goal of any interface is to transmit data between one or moreapplications 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 offailure. Generally, the more steps there are, the higher the probability of failure and thehigher the effort to develop and support the interface. This is true, no matter what thetechnology, 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 betweentwo points. The receiving interface must not start processing until all the data is receivedand is accounted for.

For example:

A customer had the problem where occasionally, not all the transactions in a file werereceived in SAP R/3. The file had been transmitted to the SAP R/3 host, had been pickedup by a polling mechanism and the ABAP interface program had been triggered toprocess the file. It turned out that in some cases, the interface was triggered prematurelyi.e. whilst the file was still being sent. This is a common problem when using FTP withlarge files. There were no mechanisms in place to detect that the file was still growing, orcontrols in the data to ensure that all the data is there. The result was loss of data and acorrupt business process!


7/24





(p) 972.267.7900 (f) 972.267.7901

Toll Free: 888.812.7226

3.2 Traceability, organization and security

Each execution of an interface should be uniquely identified (e.g. run number). Eachtechnical step within the interface run should be clearly identified and executed insequence. The overall interface run and its technical steps should be classified in businessterms e.g. Sales Order 516719, Material 100003689 etc. In addition, runs of a particularinterface may need to be grouped together into an area that is responsible for them e.g. bySAP 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 processinginformation 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 itwas 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 viewall the interface runs from a single point in R/3. They should be able to drill down onfailed runs and diagnose the cause. The interface framework should also promote pro-active monitoring by automatically notifying nominated users of any problems. This canbe achieved by email, SMS or via an external monitoring/paging system. Trend analysisis important to view how many runs are being executes, peak processing, total failures,the amount of time taken to fix problems etc.


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.


8/24





(p) 972.267.7900 (f) 972.267.7901

Toll Free: 888.812.7226

3.4 Checkpoint restart

If an error occurs, the interface should be able to be restarted from the point of failure. Inaddition a clear distinction needs to be made between technical and business errors andcontrols are necessary to enable automatic restart or if the interface can be restarted andby whom.

For example:

If an error was detected on record 900 of a 2000 transaction file, support staff should beable 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. Thisbecomes important if interfaces cannot execute at the same time, or must be executed in aparticular order. Scheduling is the ability to plan the interface run into the future orrelease it when a specific event occurs.

For example:

R/3 only allows one material movement to occur at any one time for a specificplant/material combination. If more than one is processed at a time, the others are lockedout and are failed. A warehouse management system may submit hundreds or thousandsof material movements per day to R/3. These need to be serialised by plant and materialto only allow one of each to execute at a time or else unnecessary failures will occur.


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. downtimewindow)

Ignore or fail processing if the interface has already run


9/24





(p) 972.267.7900 (f) 972.267.7901

Toll Free: 888.812.7226

4 What R/3 does not provide

Although R/3 provides many mechanisms for interfacing (BDC, IDOC, BAPI etc.) andall the low level functionality to handle processing, it is open ended with no supportingframework and consistent mechanism for implementing good interfaces. Much is left upto the developer who needs not only to implement the business logic, but also thetechnical 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 manydifferent 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 isthat developers need to spend as much time addressing the technical support aspects, asthey do implementing the business logic. A standard framework should provide all themonitoring, flow and dependency controls necessary, allowing the developer toconcentrate only on the code to implement the business logic, messages etc. In addition,many common routines for processing transactions, logging and passing data betweensteps can be reused time and time again. Sky has benchmarked that Customers will saveas much as 60% development and testing time by having a consistent interfaceframework in place.

4.2 Lack of dependency controls

Dependency controls allow developers to implement proper sequencing e.g. only allowone run at a time for a specific plant/material combination to avoid failure due to lockedresources in R/3. Serialisation and logical locking allow interface runs to execute in aspecific order, thus ensuring transaction integrity and avoiding resource-locking failures.Whilst R/3 does provide some rudimentary serialisation for some things (e.g. IDOCs), itis 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


10/24





(p) 972.267.7900 (f) 972.267.7901

Toll Free: 888.812.7226

4.3 Lack of traceability and logging mechanisms

It is nearly always necessary to audit the process of an interface i.e. provide informationon 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 createdfrom 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.


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 differentmodes. 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. The SAP system receives a file2. The file is detected in the inbound directory and moved to a processing directory

3. A job is triggered in SAP to execute a ABAP program to generate a BDC session4. The file is moved to the archive directory5. The BDC session is submitted for execution

In this simple example, there are five distinct technical steps that constitute a singleinterface run. R/3 provides no standard mechanism to logically group all the stepstogether and no central point to monitor it as such. Developers often resort to crudeprogress/status tables, which are updated along the way.


11/24





(p) 972.267.7900 (f) 972.267.7901

Toll Free: 888.812.7226

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 errorprocessing and call options to ensure they are robust and upgradeable.

R/3 does not provide standard proven common routines and utilities that may be reusedtime 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 madeconfigurable i.e. no code required. This saves considerable development, testing andsupport time, because the utilities are standard and are known to work with correct errorhandling.

For example:

In the typical interfacing scenario:

1. The SAP system receives a file2. The file is detected in the inbound directory and moved to a processing directory3. A job is triggered in SAP to execute a ABAP program to generate a BDC session4. The file is moved to the archive directory5. The BDC session is submitted for execution

The interface framework should handle all the steps (1,2,3,4,5) automatically. Thedeveloper need only provide the ABAP program to execute. In addition, the standard

framework provides all the sequencing, documentation and logging mechanisms thatwould otherwise have to be developed.


12/24





(p) 972.267.7900 (f) 972.267.7901

Toll Free: 888.812.7226

4.6 No high volume performance management

In cases where large volumes of interface runs are submitted asynchronously into SAPR/3, Customers may encounter severe performance problems with the background job,asynchronous transaction and/or IDOC sub-systems. There are no controls to limit orzone this processing to only use limited resources of the SAP system, thus flooding canoccur 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-systemsthat 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 anautomated barcode system. The result is a CO11 transaction being issued to SAP everysecond. Customers usually address these types of problems by purchasing dedicatedhardware (a expensive proposition!).

An interface framework should be able to accept these transactions and queue them to beprocessed in a continuous cycle i.e. a controlled number of dedicated batch jobs feedingoff a central transaction queue. In this way, the R/3 scheduling overhead is avoided, twiceas 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 addressthis is to use SAP workflow, which is complex, slow and expensive (both in cost andsystem resource). Conditional logic provides the ability to optionally execute parts of theinterface, depending on the data received. It enables modular solutions that may beshared between different interfaces.

4.8 No checkpoint restart capability

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


13/24





(p) 972.267.7900 (f) 972.267.7901

Toll Free: 888.812.7226

4.9 Inadequate scheduling capability

R/3 has a rudimentary scheduling system. Interfaces may need to delay or cancelprocessing under certain circumstances. R/3 does not provide adequate schedulingfunctionality 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 amaximum 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 manuallycheck these messages, before allowing the interface, or subsequent interfaces, tocontinue. This can waste valuable processing and people time. In order to automate theseinterfaces, programmers must write code to scan the logs and/or spool for errorconditions.

An interface framework should provide the ability to configure this low level ofmonitoring and the actions to take e.g. fail the run if the following message was/was notreceived.

4.11 No built-in documentation and annotation facilities

Because interfaces are usually made up of multiple technical steps and may requirespecific instructions to restart them if they fail, it is important that support staff has thisdocumentation at hand to quickly resolve a problem. It is also important to annotate theactions taken to resolve a problem for future reference. Printed materials get quickly outof date and may not be available, when the problem occurs. An interface frameworkshould provide facilities to document the interface and its steps; it should also provide astandard mechanism to annotate interface failures with comments.


14/24





(p) 972.267.7900 (f) 972.267.7901

Toll Free: 888.812.7226

5 The hidden costs of poor interfaces

It is sometimes very difficult for managers to detect how much time is wasted insupporting failed interfaces and the overall impact they have on the business. Often SAPcustomers 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 thesehidden 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 occurredo Know exactly where the interface failed and whyo Have the ability to automatically reprocess from the point of failure

Business users are empowered to monitor (possibly manage) their own interfaceso Less reliance on ITo Less delay

Recurring technical problems were eliminated through the use of a robustinterface framework

For example:

A company implemented an EDI interface with a financial institution to approve andprocess hire purchase agreements. The interface failed from time to time and wentundetected, until customers complained. The business then contacted the IT department,which then started manually tracing the transactions through the EDI interface. For eachfailure, an entire man-day of effort was expended by the business and IT to find andcorrectly resolve the customers problem. The problem was occurring at least twice aweek. The impact of this interface was 96 support days a year, lost credibility withcustomers and high administration fees with the financial institution.


15/24





(p) 972.267.7900 (f) 972.267.7901

Toll Free: 888.812.7226

6 How ECS provides complete interface management

The Event Control System (ECS) is an interface management framework developed bySky Technologies specifically for SAP R/3 interfacing. ECS provides comprehensivefunctionality to monitor and control the execution of interfaces between external systemsand 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 avariety of ways:

Exception reporting

Email (SMS)

External notification system or paging service (e.g. HP-Open view, CA-Unicenter)

This monitoring system promotes pro-active support, thus minimizing businessdowntime. ECS also provides an automatic escalation system that notifies the secondarycontact, should the primary contact not respond in a given time frame.


16/24





(p) 972.267.7900 (f) 972.267.7901

Toll Free: 888.812.7226

6.2 Monitoring

A real-time monitoring system is available, in SAP R/3, which provides information onall interfaces. Support staff can view the status of all, or specific interfaces, and can easilydrill down on problem areas. The following are just a few samples of the manytransactions 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 lineor field. In ECS terminology, an interface is known as a Process and each step is knownas a Phase. SAP security may be implemented, so that users or specific roles can onlyview certain interfaces or groups of interfaces.


17/24





(p) 972.267.7900 (f) 972.267.7901

Toll Free: 888.812.7226

6.2.2 Monitoring individual runs

The following screen shot is a breakdown of a specific interface run, showing theindividual technical steps. Failed runs may be reprocessed or force completed from thispoint. Each high level entry is a unique run of the interface, the next level down displaysthe 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 implementedfor any of these options against specific users or roles.


18/24





(p) 972.267.7900 (f) 972.267.7901

Toll Free: 888.812.7226

6.3 The ECS online workbench

The ECS online workbench is where Interface definitions and all the rules for processingare 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


19/24





(p) 972.267.7900 (f) 972.267.7901

Toll Free: 888.812.7226

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 theymay be downloaded to the PC for analysis.

Using these statistics, effective trend analysis can be performed to quickly identify hotspots, bottlenecks in processing or the effectiveness of changes. KPI (key performanceindicators) can also be checked to see how quickly failures were resolved.


20/24





(p) 972.267.7900 (f) 972.267.7901

Toll Free: 888.812.7226

6.5 Dependency and scheduling controls

ECS has comprehensive dependency controls and scheduling capability. These are oftenimplemented as standard configuration using the ECS workbench, but also may bedefined at run time within ABAP programs using the ECS SDK (software developerskit). The following table lists some of the options available:

Logical locking 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 issuccessful

Lock on a combination of values e.g. material andpurchase order

Suspend the run, waiting for manual user confirmation

Sequencing First in first out (as started)

By user specified sequence number

Specify a priority

Scheduling 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 toFriday between the hours of 8am to 6pm.

Only run the interface on certain SAP instances,utilizing a maximum of xxx background processes

It is important to note that ECS can also be used for other processing in the SAP systemas well as interfacing e.g. month end scheduling.


21/24





(p) 972.267.7900 (f) 972.267.7901

Toll Free: 888.812.7226

6.6 Restart recovery

Failure and reprocessing rules may be configured using the ECS workbench. This enablesfailed interface runs to be restarted in a controlled manner. You may also preventreprocessing under certain conditions or instruct ECS to automatically restart after afailure e.g. try x times waiting x seconds in-between.

The run detail screen highlights failed runs and the Phase (step) that the error occurredon. Support staff may then investigate or simply execute the reprocess button. Runs mayalso be undone back to a specific point.

In the above example, ECS has detected that BDC processing has failed. Support staffmay view the BDC log, instruct ECS to execute the BDC again or re-process the BDConline.


22/24





(p) 972.267.7900 (f) 972.267.7901

Toll Free: 888.812.7226

6.7 Annotation/documentation

ECS provides the facility to document Interfaces and their steps online in a number ofways. In this way, the documentation is kept up to date and is readily accessible to allsupport staff. In addition, any run or specific step of a run may be annotated to keep trackof 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


23/24





(p) 972.267.7900 (f) 972.267.7901

Toll Free: 888.812.7226

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 directoryfor a specified file name (or wild card) and automatically start an Interface when the filehas been successfully received (i.e. finished growing).

Files may be automatically copied, moved, renamed or deleted as part of the Interfacedefinition, by simply configuring options in the workbench. This saves considerabledevelopment and testing time.


24/24





(p) 972.267.7900 (f) 972.267.7901

Toll Free: 888.812.7226

7 Appendix

7.1 Contacting Sky

6504 International Pkwy. Suite 1500Plano, TX 75093www.texasbarcode.com(p) 972.267.7900(f) 972.267.7901Toll 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

Complete Interface Management Using ECS

Documents

Transcript of Complete Interface Management Using ECS