February 2008

Learn ABAP BAPI basics

Before you program a BAPI you should clearly define the processes and situations the BAPI will be used for.To define the scenario the BAPI is to be used for, consider the following issues:

• Which scenario is to be implemented?

Every BAPI should be based on a model of a scenario in which it can be usefully employed. You can describe the scenario in the form of a process model.

• Which SAP Business Objects are involved?

From the scenario definition and with the help of the process model you can get information about the SAP Business Objects relevant to the BAPI scenario.

In the scenario to be implemented, a BAPI is required to read data about a creditor. First of all, a list of creditors is to be displayed from which a specific creditor can be selected. Then, using another BAPI, specific details about this creditor are to be displayed.

The relevant SAP Business Object for this scenario is Creditor.

• What functionality should the BAPI provide and how does it affect related BAPIs, especially the other BAPIs of the SAP Business Object in question?

In line with the scenario concept BAPIs must complement each other to create a complete scenario. Their relationships with each other must be clearly defined.

To read a creditor's details as described in the above scenario, two BAPIs are required:

- Display list of creditors
- Display details of a specific creditor

The interdependency between these two BAPIs is evident because first the creditor list is displayed to obtain the ID of the specific creditor sought. From this ID, details of this creditor can then be displayed.

However, the two BAPIs remain functionally independent of each other, because if the creditor ID is known, the BAPI "Display details of a specific creditor" can be used without first calling the BAPI "Display list of creditors".

• To what extent can the BAPI's functionality be implemented within the scope of the business object?

A BAPI should be developed so that it provides functionality exclusively within the context of its associated SAP Business Object. If the data of a different SAP Business Object is to be read or updated then the appropriate interface for this object must be used. The functions or methods of these other objects are used implicitly (delegation principle).

The BAPIs required to read creditor details in the above scenario are only able to access data in the SAP Business Object Creditor. Other object types are not involved.

• Is the BAPI assigned to the SAP Business Object in a meaningful and semantically correct way?

Result

Once you have considered these issues you will be able to clearly conceptualize the functionality of the planned BAPI(s). You will also have identified the SAP Business Objects relevant to the BAPI scenario.

Review

Purpose

In the previous step you created a concept for a scenario a BAPI could be applied to. You also defined relevant SAP Business Objects.

Before you implement the scenario and begin defining and developing the BAPI, you should carry out a review of the scenario concept.

Process Flow

You should carry out the review of the BAPI scenario in cooperation with all persons involved in the BAPI development and those responsible for quality control in your development group.

Result

Start developing the BAPI only after you have successfully completed the review.

Defining a BAPI and Its Interface

Purpose

After you have carried out the review of the BAPI concept and it has been accepted, you can start defining the BAPI itself.

In this step, you will decide on the names, parameters, and characteristics of the BAPI and determine the structures the BAPI will be based on.

Only after you have planned and defined these required details can you start to implement the BAPI, as described in Creating Individual Programming Objects and Programming BAPIs.

Process Flow

To define the scope and required components of the BAPI to be implemented, the following steps must be completed:

• Determining the SAP Business Object and Its Key Fields
• Defining the Interface Structure of the BAPI
• Identifying the name of the function group, or if a function group does not exist already, planning a name for one.

All BAPIs belonging to one SAP Business Object should be stored as function modules in one function group. Ascertain whether a function group has already been created for the BAPIs of the SAP Business Object in question. If a function group does not already exist, then plan a name for the one to be created.

You can use the default technical name (object type) of the SAP Business Object as the basis of the function group name. The technical name of a SAP Business Object usually takes the form of BUSnnnn, where n is a number.

Use the suffix "nnnn" as the name of the function group. For example, if the technical name of the object is BUS1008 then the associated BAPI function group is called 1008.

To ascertain the technical name of the Business Object, open the Business Object in the Business Object Repository (BOR), as described in Determining the SAP Business Object and Its Key Fields. To display further details, for example, the object type, double click the name of the Business Object.

• Assigning a name to the function module

Choose a name that gives an indication of what the BAPI is used for. The naming convention is: BAPI__. For information about naming a method refer to Naming the Method in the BOR.

For example, in the case of a BAPI which reads details for the object type Creditor, the name of the associated function module is BAPI_CREDITOR_GETDETAIL.

• Naming Parameters in the Function Module

• Defining the format for passing the values in the function module interface.
Parameters must not be converted before they are passed to and from the BAPI interface. This is because BAPIs are programming interfaces and not end user interfaces. Exceptions are currency codes, ISO codes and fields with an internal key.

• Specifying the Required Objects in ABAP Dictionary
• Naming the Method in the BOR
• Naming Parameters in the BOR

RELATED POST

SAP architecture,its full form of working and enjoy sap products

EDI Converter for SAP

R/3 does not provide any tool to convert IDocs into international EDI format like ANSI X.12, EDIFACT or XML. This conversion needs to be done by an external add-on product which is Provided by a variety of companies who specialize in general EDI and e-commerce solutions.

R/3 does not provide conversion to EDI standard formats like X.12, EDIFACT or XML.Converters exist on UNIX and PC platforms.

Many converters are simple PC programs.

R/3 certification only guarantees that the converter complies to RFC technology and works fine with standard IDoc scenarios.

Real life situations require a flexible and easily adaptable converter program.

SAP R/3 has foregone implementing routines to convert IDocs into international EDI standard formats and forwards those requests to the numerous third party companies who specialize in commercial EDI and e-commerce solutions..

Nearly every standard organization defined an own EDI standard for their members. So there is X.12 by ANSI for the US, EDIFACT/UN adopted by the United Nations Organization UNO or XML as proposed by the internet research gurus of W3C.

But there is still more about it. All major industry companies define an additional file format standard for their EDI partners. Even if they adhere officially to one of the big standards, they yet issue interpretation guidelines with their own modifications according to their needs.

If a company does not play in the premier league of industry or banking companies, it will have to comply with the demands of the large corporations.

As this leads to the insight that there are as many different EDI formats as companies, it is evident that an EDI converter needs to have at least one major feature, which is flexibility in the sense of openness towards modification of the conversion rules.

There are hundreds of converter solutions on the market not counting the individual in-house programming solutions done by many companies.

EDI is a market on its own. Numerous companies specialize in providing EDI solutions and services. The majority of those companies also provide converters. Many of the converters are certified by SAP to be used with R/3. However, this does not tell anything about the usability or suitability to task of the products.

RELATED POST

IDOC COMPLETE

MySAP sales and distribution strategies
SAP definition,full form,over veiw and introduction
What is SAP Full form and its definition part one

EDI and International Standards for SAP

Electronic Data Interchange (EDI) as a tool for paperless inter-company communication and basic instrument for e-commerce is heavily regulated by several international standards.Unfortunately, it is true for many areas in the industry that an international standard does not mean that everybody uses the same conventions.

Too many organizations play their own game and define standards more or less compatible with those set by competing organizations.The main contenders are the national standards organizations and private companies versus the big international organizations ISO and ANSI.The private companies being backed up by their country organizations usually fight for maintaining conventions, which have been often established for many years with satisfaction.

The American National Standards Organisation ANSI and the international partner International Standards Organization ISO will usually fight for a solid open standard to cover the requirements of everybody.This generally leads to a more or less foul trade-off between pragmatism and completeness. Tragically the big organizations put themselves in question. Their publications are not free of charge. The standards are publications which cost a lot of money. So they mostly remain unread.

Nowadays computing standards have mostly been published and established by private organizations who made their knowledge accessible free of charge to everybody. Examples are manifold like PostScript by Adobe, HTML and JavaScript by Netscape, Java by SUN, SCSI by APPLE, ZIP by PK Systems or MP3 by – who cares, XML by W3C and EDIFACT by the United Nations Organization UNESCO.

The well-known standards EDIFACT, X.12 and XML have similar characteristics and are designed like a document description language. Other standards and R/3 IDocs are based on segmented files.

ANSI X.12 is the US standard for EDI and e-commerce. Why is it still the standard? There are chances that X.12 will be soon replaced by the more flexible XML, especially with the upcoming boost of e-commerce. ANSI X.12 is a document description language.

An ANSI X.12 message is made up of segments with fields. The segments have a segment identifier and the fields are separated by a special separator character, e.g. an asterisk.

BEG*00*NE*123456789**991125**AC~

EDIFACT was originally a European standard. It became popular when chosen by the UNO for their EDI transactions. EDIFACT is a document description language. EDIFACT is very similar to ANSI X.12 and differs merely in syntactical details and the meaning of tags.

XML and the internet page description language HTML are both subsets derived from the super standard SGML...The patent and trademark holder of XML describes the advantages of XML very precisely as follows.

1. XML is a method for putting structured data in a text file.

2. XML looks a bit like HTML but isn't HTML.

3. XML is text, but isn't meant to be read.

4. XML is verbose, but that is not a problem.

5. XML is license-free and platform-independent.

And XML is fully integrated in the world wide web. It can be said briefly: XML sends the form just as the customer entered the data.

XML

This is an excerpt of an XML EDI message. The difference from all other EDI standards is that the message information is tagged in a way that it can be displayed in human readable form by a browser.XML differs from the other standards. It is a document markup language like its sister and subset HTML.XML defines additional tags to HTML, which are specially designed to mark up formatted data information.The advantage is that the XML message has the same information as an EDIFACT or X.12 message. In addition, it can be displayed in an XML capable web browser .

EDI CONTINUIED

What is SAP and Why do we are in need of It

What is SAP Full form and its definition part one

Batch Input Recording for inbound Idoc

The batch input (BTCI) recorder (SHDB) is a precious tool to develop inbound IDocs. It records any transaction like a macro recorder. From the recording, an ABAP fragment can be created.This lets you easily create data input programs without coding new transactions.The BTCI recorder lets you record the screen sequences and values entered during a transaction. It is one of the most precious tools in R/3 since release 3.1. It allows a fruitful cooperation between programmer and application consultant.

The section below will show you an example of how the transaction SHDB works.With the recording, you can easily create an ABAP which is able to create BTCI files.You will be asked for a session name and the name of the transaction to record.Then you can enter the data into the transaction as usual.After you finished the recording, you have the possibility to generate ABAP coding from it. This will be a sequence of statements which can generate a batch input session, which is an exact replay of the recorded one.

The generated program contains an include BDCRECXX which contains all the FORM routines referenced.To make the recorded code usable for other programs, you should make a function module out of it. Starting with release 4.5A the recorded code provides a feature to automatically generate such a function module.

How to Use the Recorder Efficiently

This routine replaces BDCRECXX to allow executing the program generated by SHDB via a call transaction instead of generating a BTCI file.

The SHDB transaction creates an ABAP from the recording. When you run this ABAP, it will generate a BTCI group file, with exactly the same data as in the recording.

The recorder is able to generate an ABAP. Releases before 4.5A include a routine BDCRECXX. This include contains FORM routines which fill the BDCDATA table and execute the routines BDC_OPEN_GROUP and BDC_CLOSE_GROUP. These are the routines which create batch input files.

If we modify this FORM routines a little bit, we can make the ABAP replay the recording online via a CALL TRANSACTION, which is much more suitable for our development and testing purposes. If you replace the standard include BDCRECXX with the shown one ZZBDCRECXX, you can replay the recording online.

Starting with release 4.5A you can create a function module from the recording.This function module replaces the recorded constants with parameters and gives you the option to choose between a batch input file or a direct call transaction.

A remark on screen processing, if there are table controls (scroll areas). If you enter many lines or try to extend a list, it will be impossible to tell where to place the cursor. Therefore, most transactions provide a menu option that positions the list in a calculable manner. If you choose a new item, most transactions will either pop up a detail screen or will position the list, so that the next free line is always line 2.If this feature is not provided in a transaction, it is regarded as a malfunction by SAP and can be reported to SAPNET/OSS.

ZZBRCRECXX_FB_GEN: Generate a Function from Recording

The ABAP generated by SHDB is a very useful tool for developers. However, it does not replace the recorded constants by variables.The following routine generates a function module from the recording. All you have to do is put the coding below in an include.

Give it the name ZZBDCRECXX_FBGEN.

Then replace the include BDCRECXX in the recording with ZZBDCRECXX_FBGEN.

When you execute the ABAP, a function module in an existing function group will be created. The created function will contain the recording with all the constants replaced by variables, which show in the function module interface.

The following useful routine is written for releases up to 4.0B. In release 4.5B a similar functionality is provided. You can generate a function module from the recording transaction directly.Before you generate the function, a function group must exist. This you have to do manually. The function group must also contain the include ZZBDCRECXX to have the declarations of the referenced FORM routines.

The created function module should work without modification for testing at least.However, you probably will need to modify it, e.g. by adding a loop for processing multiple entries in a table control (scroll area).

RELATED POST

RFC AND TROUBLE SHOOTING

MySAP sales and distribution strategies
SAP definition,full form,over veiw and introduction
What is SAP Full form and its definition part one

R/3 RFC/OLE Troubleshooting

Problems connecting via RFC can usually be solved by reinstalling the full SAPGUI and/or checking your network connection with R/3.If you have problems to connect to R/3 via the RFC DLLs then you should check your network installation. It would be out of the reach of this publication to detail the causes and solutions when an RFC connection does not work.In most cases a full install of the SAPGUI on the computer which runs the calling program will secure a reliable connection, provided that you can login to R/3 problem-free with this very same SAPGUI installation.

Another trivial but often cause are simple network problems. So impossible it may appear, you should always go by the book and first check the network connection by pinging the R/3 system with the PING utility and checking the proper access authorities.However, if you successfully passed the SAPlogon method, then the problem is mostly a misspelling of object or method names or an incompatibility of the called function.

If you are quite sure that you spelled everything right and correct, and still get an error executing the SAP.FUNCTIONS.CALL method then you should investigate the function module in R/3.Generate the function group to see if there is an syntax error.

Make sure that the function is tagged as RFC allowed.

RELATED POSTS

QUEUED RFC
RFC PART 3
RFC PART 2

What is SAP Full form and its definition part one

R/3 RFC from MS Office Via Visual Basic

The Microsoft Office suite incorporates with Visual Basic for Applications (VBA) a fully object oriented language. JavaScript and JAVA are naturally object oriented. Therefore you can easily connect from JavaScript, JAVA, WORD, EXCEL and all the other VBA compliant software to R/3 via the CORBA compatible object library (in WINDOWS known also DLLs or ACTIVE-X (=OLE/2) components).

Visual Basic is finally designed as an object oriented language compliant to DCOM standard.JavaScript is a typical object oriented language which is compliant to basic CORBA,DCOM and other popular object standards.

SAP R/3 provides a set of object libraries, which can be registered with Visual Basic. The library adds object types to VBA which allow RFC calls to R/3. The libraries are installed to the workstation with the SAPGUI installation. They are technically public linkable objects, in WINDOWS these are DLLs or ACTIVE-X controls (which are DLLs themselves).

The object library SAP contains among others the object type FUNCTIONS whose basic method CALL performs an RFC call to a specified R/3 function module. With the call you can pass object properties which will be interpreted as the interface parameters of the called function module.

If the RFC call appear not to be working, you should first try out to call one of the standard R/3 RFC function like RFC_CALL_TRANSACTION_USING (calls a specified transaction or RFC_GET_TABLE (returns the content of a specified R/3 database table).SAP R/3 provides a set of object libraries, which can be registered with JavaScript to allow RFC calls to R/3.

The object library SAP contains among others the object type FUNCTIONS whose basic method CALL performs an RFC call to a specified R/3 function module. If the RFC call appears to be not working, you should first try out to call one of the standard R/3 RFC functions like RFC_CALL_TRANSACTION_USING (calls a specified transaction) or RFC_GET_TABLE (returns the content of a specified R/3 database table).

Call Transaction From Visual Basic for WORD 97

This is a little WORD 97 macro, that demonstrates how R/3 can be called with a mouse click directly from within WORD 97.This macro calls the function module RFC_CALL_TRANSACTIION_USING . This function executes a dynamic call transaction using the transaction code specified as the parameter.

You can call the macro from within word, by attaching it to a pseudo-hyperlink. This is done by adding a MACROBUTTON field to the WORD text. The macrobutton statement must call the VBA macro R3CallTransaction and have as the one and only parameter the name of the requested transaction MACROBUTTON R3CallTransaction VA02 This will call transaction VA02 when you click on the macrobutton in the text document. You can replace VA02 with the code of your transaction.

R/3 RFC from JavaScript

JavaScript is a typical object oriented language which is compliant to basic CORBA,DCOM and other popular object standards.SAP R/3 provides a set of object libraries, which can be registered with JavaScript to allow RFC calls to R/3.

The libraries are installed to the workstation with the SAPGUI installation.The object library SAP contains among others the object type FUNCTIONS whose basic method CALL performs an RFC call to a specified R/3 function module.If the RFC call appears to be not working, you should first try out to call one of the standard R/3 RFC functions like RFC_CALL_TRANSACTION_USING (calls a specified transaction) or RFC_GET_TABLE (returns the content of a specified R/3 database table).

RELATED POSTS

QUEUED RFC
RFC PART 3
RFC PART 2
What is SAP and Why do we are in need of It
What is SAP Full form and its definition part one

Creating IDocs and ALE Interface from BAPI

There is a very powerful utility which allows you to generate most IDoc and ALE interface objects directly from a BAPI’s method interface.Every time BAPI is executed, the ALE distribution is checked.

For each of the parameters in the BAPI's interface, the generator created a segment for the IDoc type. Some segments are used for IDoc inbound only; others for IDoc outbound instead. Parameter fields that are not structured will be combined in a single segment which is placed as first segment of the IDoc type and contains all these fields. This collection segment receives the name of the IDoc type.

Defining Filter Rules :

ALE allows you to define simple filter and transformation rules. These are table entries which are processed every time the IDoc is handed over to the port. Depending on the assigned path, this happens either on inbound or outbound.Using the OLE/Active-X functionality of R/3 you can call R/3 from any object aware language.Actually it must be able to do DLL calls to the RFC libraries of R/3. SAP R/3 scatters the documentation for these facilities in several subdirectories of the SAPGUI installation.R/3 can exchange its IDoc by calling a program that resides on the server The programs can be written in any language that supports OLE-2/Active-X technology Programming skills are mainly required on the PC side, e.g. you need to know Delphi, JavaScript or Visual Basic well .

RELATED LINKS

ALE PART 6
ALE PART 5
What is SAP and Why do we are in need of It
What is SAP Full form and its definition part one

Useful ALE Transaction Codes

ALE is customised via three main transaction. These are SALE, WEDI and BALE.This is the core transaction for SALE customizsng. Here you find everything ALE related which has not already been covered by the other customising transactions.

WEDI - IDoc Administration :

Here you define all the IDoc related parts, which make up most of the work related to ALE.BDBG - Automatically generate IDocs From A BAPI :

Good stuff for power developers. It allows you to generate all IDoc definitions including segments and IDoc types from the DDIC entries for a BAPI definition.

ALE Customizing SALE

All ALE special customiing is done from within the transaction SALE, which links you to a subset of the SAP IMG.The scenario defines the IDoc types and the pairs of IDoc partners which participate in the ALE distribution. The distribution scenario is the reference for all ABAPs and functionality to determine which data is to be replicated and who could be the receiving candidates. This step is, of course, mandatory.

The change pointers can be used to trigger the ALE distribution. This is only necessary if you really want to use that mechanism. You can, however, send out IDocs every time an application changes data. This does not require the set-up of the change pointers.SAP allows the definition of rules, which allow a filtering of data, before they are stored in the IDoc base. This allows you to selectively accept or decline individual IDoc segments.

ALE allows the definition of conversion rules. These rules allow the transition of individual field data according mapping tables. Unfortunately, the use of a function module to convert the data is not realized in the current R/3 release.

The filter and conversion functionality is only attractive on a first glance. Form practical experience we can state that they are not really helpful. It takes a long time to set up the rules, and rules usually are not powerful enough to avoid modifications in an individual scenario. Conversion rules tend to remain stable, after they have once been defined. Thus, it is usually easier to call an individual IDoc processing function module, which performs your desired task more flexibly and easily.

Basic settings have to be adjusted before you can start working with ALE.Before we start, we need to maintain some logical systems. These are names for the RFC destinations which are used as communication partners. An entry for the logical system is created in the table TBDLS.

Finally. you will have to assign a logical system to the clients involved in ALE or IDoc distribution. This is done in table T000, which can be edited via SM31 or via the respective SALE tree element.The distribution model (also referred to as ALE-Scenario) is a more or less graphical approach to define the relationship between the participating senders and receivers. The distribution model is shared among all participating partners. It can, therefore, only be maintained in one of the systems, which we shall call the leading system.

Only one system can be the leading system, but you can set the leading system to any of the partners at any time, even if the scenario is already active. This will be the name under which you will address the scenario. It serves as a container in which you put all the from-to relations.

You can have many scenarios for eventual different purposes. You may also want to put everything in a single scenario. As a rule of thumb, it proved as successful that you create one scenario per administrator. If you have only one ALE administrator, there is no use having more than one scenario. If you have several departments with different requirements, then it might be helpful to create one scenario per department.

The model view displays graphically the from-to relations between logical systems. You now have to generate the partner profiles which are used to identify the physical means of data transportation between the partners.

A very useful utility is the automatic generation of partner profiles out of the ALE scenario.Even if you do not use ALE in your installation, it could be only helpful to define the EDI partners as ALE scenario partners and generate the partner profiles.If you define the first profile for a partner, you have to create the profile header first.

The partner class is only a classification value. You can give an arbitrary name in order to group the type of partners, e.g. EDI for external ones, ALE for internal ones, and IBM for connection with IBM OS/390 systems.

ALE Distribution Scenario

ALE is a simple add-on application based on the IDoc concept of SAP R/3. It consists of a couple of predefined ABAPs which rely on the customisable distribution scenario. These scenarios simply define the IDoc types and the pairs of partners which exchange data.ALE defines the logic and the triggering events which describe how and when IDocs are exchanged between the systems. If the ALEE engine has determined which data to distribute, it will call an appropriate routine to create an IDoc. The actual istribution is then performed by the IDoc layer.

The predefined distribution ABAPs can be used as templates for own development ALE uses IDocs to transmit data between systems.ALE is, of course, not restricted to the data types which are already predefined in the BALE transaction. You can write your ALE distribution handlers which should only comply with some formal standards, e.g., not bypassing the ALE scenarios.

All ALE distribution uses IDocs to replicate the data to the target system. The ALE applications check with the distribution scenario and do nothing more than call the matching IDoc function module, which is alone responsible for gathering the requested data and bringing them to the required data port. You need to thoroughly understand the IDoc concept of SAP beforehand, in order to understand ALE.

The process is extremely simple: Every time a data object, which is mentioned in an ALE scenario changes, an IDoc is triggered from one of the defined triggering mechanisms. These are usually an ABAP or a technical workflow event.

Distribution ABAPs are started manually or can be set up as a triggered or timed batch job. Sample ABAPs for ALE distribution are those used for master data distribution in transaction BALE, like the ones behind the transaction BD10, BD12 etc.The workflow for ALE is based on change pointers. Change pointers are entries in a special database entity, which record the creation or modification of a database object. These change pointers are very much like the SAP change documents. They are also written from within a change document, i.e. from the function CHANGEDOCUMENT_CLOSE. The workflow is also triggered from within this function.

SAP writes those ALE change pointers to circumvent a major draw back of the change documents. Change documents are only written if a value of a table column changes, if this column is associated with a data element which is marked as relevant for change documents (see SE11). ALE change pointers use a customised table which contains the names of those table fields which are relevant for change pointers.

ALE Application Link Enabling introduction

ALE is an R/3 technology for distribution of data between independent R/3 nstallations. ALE is an application which is built on top of the IDoc engine. It simply adds some structured way to give R/3 a methodical means to find sender, receiver, and triggering events for distribution data.

Make Use of ALE for Your Developments :

Transfer master data for material, customer, supplier and more to a different client or system with BALE Copy your settings for the R/3 classification and variant configurator to another system, also in BALE Copy pricing conditions with ALE from the conditions overview screen (e.g. VV12 ).

Distribution Scenario Based on IDocs:

ALE has become very famous in business circles. While it sounds mysterious and like a genial solution, it is simply a means to automate data exchange between SAP systems. It is mainly meant to distribute data from one SAP system to the next. ALE is a mere enhancement of SAPEDI and SAP-RFC technology.ALE is an SAP designed concept to automatically distribute and replicate data between webbed and mutually trusting systems .

EXPLANATION :

Imagine your company has several sister companies in different countries. Each company uses its own local SAP installation. When one company creates master data, e.g., material or customer master, it is very likely that these data should be known to all associates. ALE allows you to immediately trigger an IDoc sent to all associates as soon as the master record is created in one system.

Another common scenario is that a company uses different installations for company accounting and production and sales. In that case, ALE allows you to copy the invoices created in SD immediately to the accounting installation.

ALE defines a set of database entries which are called the ALE scenario. These tables contain the information as to which IDocs shall be automatically replicated to one or more connected R/3-compatible data systems.

To conclude ALE is not a new technology. It is only a handful of customizing settings and background routines that allow timed and triggered distribution of data to and from SAP or RFC-compliant systems. ALE is thus a mere enhancement of SAP-EDI and SAP-RFC technology.

Example :

Let as assume that we want to distribute three types of master data objects: the material master, the creditor master, and the debtor master.Let us assume that we have four offices. This graphic scenario shows the type of data exchanged between the offices. Any of these offices operates an its own stand alone R/3 system. Data is exchanged as IDocs which are sent from the sending office and received from the receiving office.

Workflow from Change Documents

Every time a change document is written, a workflow event for the change document object is triggered. This can be used to chain unconditionally an action from a transaction.

The most interesting chaining point for workflow events is the creation of the change document. Nearly every transaction writes change documents to the database. This document is committed to the database with the function module CHANGEDOCUMENT_CLOSE. This function will also trigger a workflow event.

The workflow handler triggered by an event which is fired from change documents is defined in table SWECDOBJ . For every change document type, a different event handler can be assigned.This is usually a function module and the call for it is the following:

CALL FUNCTION swecdobj-objtypefb

EXPORTING

changedocument_header = changedocument_header objecttype = swecdobj-objtype

IMPORTING

objecttype = swecdobj-objtype

TABLES

changedocument_position = changedocument_position.

Change pointers are created by calling FUNCTION CHANGEDOCUMENT_CLOSE which writes the usual change documents into table CDHDR and CDPOS. This function then calls the routine CHANGE_POINTERS_CREATE, which creates the change pointers.

CALL FUNCTION 'CHANGE_POINTERS_CREATE'

EXPORTING

change_document_header = cdhdr

TABLES

change_document_position = ins_cdpos.

Trigger a Workflow from Messaging :

The third common way to trigger a workflow is doing it from messaging.When the R/3 messaging creates a message and processes it immediately, then it actually triggers a workflow. You can use this to set up conditional workflow triggers, by defining a message with the message finding and link the message to a workflow.

You define the message the usual way for your application as you would do it for defining a message for SAPscript etc. As a processing media you can assign either the type W for workflow or 8 for special processing.The media type W for workflow would require defining an object in the object repository. We will only show how you can trigger the workflow with a standard ABAP using the media type 8.

You need to assign a program and a form routine to the message in table TNAPR. The form routine you specify needs exactly two USING-parameters as in the example below.

TABLES: NAST.

FORM ENTRY USING RETURN_CODE US_SCREEN.

na call your workflow action

RETURN_CODE = 0.

SY-MSGID = '38'.

SY-MSGNO = '000'.

SY-MSGNO = 'I'.

SY-MSGV1 = 'Workflow called via NAST'.

CALL FUNCTION 'NAST_PROTOCOL_UPDATE'

EXPORTING

MSG_ARBGB = SYST-MSGID

MSG_NR = SYST-MSGNO

MSG_TY = SYST-MSGTY

MSG_V1 = SYST-MSGV1

MSG_V2 = SYST-MSGV2

MSG_V3 = SYST-MSGV3

MSG_V4 = SYST-MSGV4

EXCEPTIONS

OTHERS = 1.

ENDFORM.

In addition, you need to declare the table NAST with a tables statement public in the ABAP where the form routinely resides. When the form is called, the variable NAST is filled with the values of the calling NAST message.

WORK FLOW PART 4

WORK FLOW PART 3

ERP sap Business process cycle for abaper

Workflow Technology

There are two faces of workflow in R/3. One is the business oriented workflow design as it is taught in universities. This is implemented by the SAP Business Workflow. However, the workflow is also a tool to link transactions easily. It can be used to easily define execution chains of transactions or to trigger user actions without the need to modify the SAP standard code. This can even be achieved without laboriously customising the HR related workflow settings.

Workflow event linkage allows the execution of another program when a transaction finishes.

The workflow event linkage mechanism can be easily used without customising the full workflow scenarios.

This way we use the workflow engine to chain the execution of transaction and circumvent the setup of the SAP Business Workflow.

There are several independent ways to trigger the workflow event linkage.

Workflow in R/3 and Its Use for Development :SAP R/3 provides a mechanism, called Workflow that allows conditional and unconditional triggering of subsequent transactions from another transaction. This allows you to build up automatic processing sequences without having the need to modify the SAP standard transactions.

The transaction to enter the graphical model, to define the events and objects, and to develop necessary triggering and processing objects is SWO1 (It is an O not a zero).

Fortunately, the underlying mechanism for workflows is less complex as the formal
overhead. Most major transactions will trigger the workflow via SWE_EVENT_CREATE . This will make a call to a workflow handler routine, whose name can usually be customised dynamically and implemented as a function module.

Contrary to what you mostly hear about R/3 workflow, it is relatively easy and mechanical to define a function module as a consecutive action after another routine raised a workflow event.For example, this can be used to call the execution of a transaction after another one has finished.

The whole workflow mechanism is based on a very simple principle. Every workflow enabled transaction will call directly or indirectly the function module during SWE_EVENT_CREATE update.

The function module SWE_EVENT_CREATE will then consult a customising table.
For a simple workflow coupling, the information is found in the table SWETYPECOU . The table will tell the name of the subsequent program to call, either a function module or an object method.

This way of defining the subsequent action is called type coupling because the action depends on the object type of the calling event.

The call to the following event is done with a dynamic function call. This requires that the called function module has a well-defined interface definition. Here you see the call as it is found in SWE_EVENT_CREATE .

CALL FUNCTION typecou-recgetfb " call receiver_type_get_fb

EXPORTING

objtype = typecou-objtype
objkey = objkey
event = event
generic_rectype = typecou-rectype

IMPORTING

rectype = typecou-rectype

TABLES

event_container = event_container

EXCEPTIONS

OTHERS = 1.

Call Function 'CHANGE_POINTERS_READ'

RELATED POSTS

WORK FLOW PART 4
WORK FLOW PART 3

ERP sap Business process cycle for abaper

Subscribe to: Posts ( Atom )