Prerequisites:

  • You have some basic knowledge of AIF
  • You would like to implement your custom functionality in toolbar
  • You are a ABAPer.


There are two alternative approaches to achieve this:

Ⅰ. Through the custom configure,

      1, To copy the standard status '/AIF/ERROR_HANDLING_TRANS/0300' to your 'Z' status, add your custom function code.

      2.png

      2, To copy the standard 'Action handler' class '/AIF/CL_AIF_ACTION_HANDLER' to your 'Z' class.

          Add a method, keep name with 'ON_[FunctionCode]_[Number]' format, number means the view number,

          you can find similar method in this class. For my example, the method name is 'ON_SIMU_0'.

       3.png

      3, To open the 'Define Applications' in /n/AIF/CUST. To replace 'Action handler' with your 'Z' class, type your custom status here.

       1.png

     4, When you click the button on toolbar in /n/AIF/ERR, Result will be like this:

      10.png

Ⅱ. Through BADI.

     1, You can easily find there are some useful enhancement spots in '/AIF/ERROR' package,

         what we wanted is '/AIF/V1_ACT' BADI. Also you can implement other BADI which works for other view.

         To create a enhancement implementation,

      5.png

     2, and create a BADI implementation under it.

      6.png

     3, 'GET_FUNC_LIST' is used to set the function code,

         'DO_ACTION' is do action when you click button,

      7.png

      8.png

      9.PNG

     4, When you click the button on toolbar in /n/AIF/ERR, Result will be like this:

      11.png

 

You will find it is more flexible using BADI to achieve same functionality, due to you can according values in 'AIF KEYS'

to decide this interface whether have this toolbar button.

This is my first blog, hope it`s useful, Please feel free give me suggestion or comments.

 

Best regards,

Archer

SAP AIF provides robust error handling mechanism along with Alert Notification where Alerts can be triggered to specific Recipient in case of Application Error. However, sometimes it is required to distribute the alerts to different Recipients based on who sent the message (e.g. If Sender system is ‘SenderSys1’ then Alert should be triggered to “Recipient1”).

 

SAP AIF Provides key field based Recipient determination for this purpose. This document explains steps to configure key field based recipient determination.

 

Step1: Define Index table containing the field on which you need to raise alert: Copy /AIF/STD_IDX_TBL into interface specific index table (e.g. Y0001_IDX_TBL). Add required Key Field on which routing needs to be defined (e.g. Sender System)

 

Image1.jpg

 

Step is only required if field on which recipient is determined is not available in AIF’s standard index table /AIF/STD_IDX_TBL.

 

Step 2: Assign Index table to your interface

 

Image2.jpg

 

Image3.jpg

Step 3: Define Alert recipient table by copying /AIF/T_ALRT_DEF

 

This table will be used to identify routing conditions for determining Recipients.

 

Image4.jpg

 

Step 4: Define different Recipients (Error Handling ->Namespace Specific Features ->Define Recipients)

 

Image5.jpg

 

Step 5: Assign different users to Recipients (System Configuration ->Assign Recipeints)

Image6.jpg

 

Step 6: Populate the table with different Recipients based on Key Fields value:

 

Image7.jpg

 

Step 7: Use custom Alert recipient table in Error Handling -> Namespace Specific Features ->Configure Alerts. Recipients will be identified based on this table by supplying key fields from Source message.

Image8.jpg

 

Assign appropriate alert category to be used.

Step 8: Define key field and assign that as to be used in Alert Recipient Determination in Error Handling -> Interface Specific Features.

Image9.jpg

 

 

After this configuration, if you execute your message and if it fails , Alert will be triggered to specific recipient based on Sender System. This can be changed to any particular fields from Payload (e.g. Company code or Department).

 

Limitation: Key Field based Alert determination is not allowed when Multi. Selection Type is selected as “Multiple Selection” (i.e. the data messages are selected from the multiple index table)

 

Image10.jpg

In /AIF/IDOC_GEN, you work with IDoc Types which start with "/". 1.png

You might get error message like "Separator '/' for namespace not paired or in wrong position" below.

2.png

This is due to that "/" as a special character should only be in the first place if it is contained in a structure name. Don’t worry! /AIF/IDOC_GEN has provided you an option to solve this issue. You can proceed with the next step by clicking below Continue button.

2 - Copy.png

 

Then you will see below screen for your confirmation.

3.png

Try to replace all "/" with "_" in Raw Data Structure column and press F8 to continue, you will succeed in generating the objects.

5.png

Prerequisites:

  • You have Inbound synchronous ABAP-Proxy
  • You would like to implement AIF Interface for your Proxy.
  • You have a developer key

As example, we will use simple inbound interface for bank data:

1.jpeg

First, we have to create RAW structure for our interface. I create RAW structure ZAIF_BANK_SAP_N in se11:

 

Screenshot 2014-04-10 18.31.jpeg

5.png

Screenshot 2014-04-10 18.32.jpeg4.png

We shouldn’t define SAP structure because this is our generated Proxy structure.

Now, go to /n/AIF/CUST_IF transaction and create an interface BANK_IN (you should use your predefined namespace):

6.jpeg

Hint: when you enter Proxy class name and press enter, Raw Data Structure and Record Type In Raw Structure will filled automatically.

 

Then we have to define an action…

7.jpeg

…and a function module for this action:

8.jpeg

Note, that we should enter Associated Type name for parameter CURR_LINE:

9.jpeg

Then we have to implement our FM. If you would like to insert some data from your SAP structure, you should use curr_line-request structure. To send your response (ext_id in our case)  to proxy response, we have to put it to curr_line-response structure.

I just fill curr_line-response-ext_id with value ‘0001’ :

10.jpeg

Save and activate FM.

Then, we have to define Structure Mapping. Click New Entries and add IMPORT_PARAM as source structure:

11.jpeg

Choose our source structure, click “Assign Destination Structure” and assign LINES as destination structure:

12.jpeg

Save and click Define Field Mappings. You have to define field mappings as on the picture:

13.jpeg

Then define created above Action as described and save.

14.jpeg

I will not describe configuration steps like creating and assigning recipients, you can find it in other docs about AIF.

As the last step, we have to implement our Proxy class ZCL_BANK_IN with code like this:

method ZII_BANK_IN~BANK_IN.

 

DATA: lt_return     TYPE bapiret2_tab.

DATA:

lv_message_id TYPE sxmsmguid,

ls_sap_data TYPE ZAIF_BANK_SAP_N,

ls_input TYPE ZMT_BANK.

 

ls_input = input.

 

cl_proxy_access=>get_inbound_message_key(     "getting message key

    IMPORTING

      message_id     = lv_message_id ).

 

call FUNCTION '/AIF/FILE_PROCESS_DATA'       "call FM to create an AIF message

  EXPORTING

      ns = 'MD'

      ifname = 'BANK_IN'

      ifversion = '1'

      transform_data = 'X'

ximsgguid              = lv_message_id

      xi_flag = 'X'

 

TABLES

      return_tab = lt_return

    CHANGING

      data = ls_sap_data

      raw_struct = ls_input-mt_bank "pass record type

    EXCEPTIONS

      not_found = 1

      customizing_incomplete = 2

      max_errors_reached = 3

      cancel = 4

      err_log = 5

      OTHERS = 6.

 

output-MT_BANK_RESP-ext_id = ls_sap_data-lines-response-EXT_ID. "assign the ext_id to proxy response

 

endmethod.

 

So, lets try to test our interface using proxy test:

15.jpeg16.jpeg

Yoo-hoo! We get back an answer to our proxy Now, go to /n/AIF/ERR, select our interface, click “Today” in Generic Selection and Select All in Status Selection and Execute:

17.jpeg

18.jpeg

Note, that you will not see a payload of your message when it sent from test tool in sproxy. To see a payload, you need two things:

1) Turn on logging for synchronous messages in tcode sxmb_adm: Integration Engine Configuration —> Category: RUNTIME —> add new parameter LOGGING_SYNC with value “1”.

2) Send message from your PI/PO system.

 

Hope this blog was helpful

 

p.s. Special thanks to George Gita

In this article I will try to present the main differencies between 3 SAP technologies which are used in SAP integration projects on the SAP backend systems (like ERP, SCM, etc.) for handling interface related errors:

 

 

a) SXMB_MONI - standard monitor for proxy messages

 

 

b) FEH/ECH - Forward error handling, Error and Conflict Handler - standard SAP tool for enterprise service error solving

 

 

c) AIF - Application Interface Framework - additional tool from SAP for interface monitoring

 

 

A similar comparision was already done in this article - POV: FEH or AIF or Custom Error Handling - but since then there have been some significant changes in some of those technologies so I believe it's worth to do the comparision once more.

 

 

Zrzut ekranu 2014-01-22 o 18.18.56.png

 

 

FEH/ECH

AIF

SXMB_MONI

Works for inbound asynchronous services
Works for inbound asynchronous services
Works for inbound asynchronous services

 

Works for outbound asynchronous services

Works for outbound asynchronous services

 

Works for inbound synchronous services

Works for inbound synchronous services

Works for outbound synchronous servicesWorks for outbound synchronous services
SAP Standard services use ECHNeeds to be customized (no coding required)SAP Standard services use SXBM_MONI
Payload editorPayload editorPayload editor based on XML
Manual restartingManual restartingManual restarting
Automated error resolution based on error typeVery limited automated restartingVery limited automated restarting
Alerting, NotificationAlerting, Notification also based on content of the messageAlerting, Notification
SXMB_MONI - integration - linksSXMB_MONI - integrated
Data search on the basis of message attributesData search on the basis of message attributes from indexed tables
Usage of tips and hints Usage of tips and hints
Authorization concept with payload attributes usage
Framework for implementing error handling - only Framework for implementing all kinds interfaces (IDOC, WS, etc.)
IDOC monitoring in the same tool (look and feel)
Own runtime for processing other types of integrations (file, etc.)
Simple navigation from error to the field level
Value mapping tables are the AIF standard objects
Grouping of interface based on defined criteria
Message mapping tool for additional mapping
Versions of interfaces
Customizable application tabs (with own objects)
Does not link to the documents Customized links to documentsDoes not link to the documents
Licence cost - freeLicence cost - Seperate LicenceLicence cost - free

 



I hope some of you can use this information to determine what kind of error handling tool do you need in your projects.


AIF allows configuring multiple selection tables for indexing values which may appear in a single message more then once (for example material number in lines of a sales order). AIF cookbook however does not provide the info how to create such tables. In this short article I will quickly describe the procedure.

 

Step 1

 

Copy table - /AIF/STD_IDX_TBL to your custom table and insert one new field - Counter - after the field MESGUID. Make sure it has the same attributes as per screenshot below:

 

a) key field - checked

 

b) initial value  - checked

 

c) data type - int4

 

index_1.JPG

 

Now you can add your key fields to the table (this you can do in the same way as you'd when working with single index tables)

 

Step 2

 

Once you save and activate your multiple index table you can use for your AIF interface. To do this you need to go to - /AIF/CUST - Error Handling - Interface Specific Features, select the Key field name, Data element, Parameter, Field-name and you need to select "Multiple selection type" field as - Multiple selection.

 

index_2.JPG

 

 

 

NOTE

Make sure you don't put the multiple index table in transaction /AIF/CUST - Error Handling - Interface Specific Features as there you can only put single index tablels.

Proxies:

 

With the previous versions of AIF 2.0 if you wanted to monitor your standard proxies you had to call the AIF enabler (method - /aif/cl_enabler_proxy=>process_message) in a proxy's BADI, ehnancement or modification. However a few months ago a new functionality was added which calls the AIF on the basis layer so it's no longer necessary to make any changes to the standard proxy implementation in case you want to use AIF. You only need to do the standard AIF configuration for the interface if you implement - Note 1799544 - Support of Enterprise Services and existing proxy interfaces.There's only prerequisite - Error and Conflict Handler (ECH) cannot be activated in client specific customizing (please have a look inside the OSS note for more details).

 

IDOCs:

 

With IDOCs the story was a bit different than with proxies. It was possible to use AIF with IDOCs without any additional development but we had to use IDOC engine in all entries in the Interface engines configuration. That had a negative functionality impact that we couldn't use index tables for example. The old configuration is described in my blog: Michal's tips: Application Interface Framework (AIF) 2.0 - monitoring existing IDOCs

If we wanted to use index tables we had to call the AIF enabler function (/AIF/IDOC_INBOUND_PROCESS_FUNC) as described in my other blog:

Michal's tips: Application Interface Framework (AIF) - IDOC processing with AIF actions Currenly with OSS note Note 1844352 - Support of Generic IDOC Monitoring we don't need to do that to call AIF enabler for IDOC scenarios. Again as with proxy interfaces AIF is being called in the basis layer so we can turn on AIF monitoring by simply doing the AIF customizing.

 

Limitations for both cases

 

Calling AIF from the basis layer in both cases (IDOC and proxy) means that we can use:

 

- Interface Monitor

 

- Index Tables

 

- Key Fields

 

- Authorizations

 

But the current limitation is that the the runtime features (like value mappings, checks) don't work so if you want to use those functions you still need to use the old way of explicitly calling the AIF enabler class/function.

 

When IDOC messages are coming to SAP backend system via AIF just like shown in my previous article: Michal's tips: Application Interface Framework (AIF) - IDOC processing with AIF actions sometimes we may need to investigate if the mapping in PO/PI was correct but it turnes out there's no easy in AIF to link PO/PI's message ID with AIF message. In case this would required in your system you can do that however in the way shown below. PO/PI's message ID is always stored in control record of the IDOC in the arckey field in such a format (this is the format for java IDOC adapter and not for ABAP based IDOC adapter):

 

 

1. Sender language:

    Length: 1

    Offset: 17

2. Receiver language:

    Length: 1

    Offset: 18

3. XI Message Id:

    Length: 32

    Offset: 20

    Format: uppercase, without hyphen

4. Original IDoc number:

    Length: 16

    Offset: 54

 

If we want to display it in the AIF message log we can use standard helped class /AIF/UTIL_ADD_MSG to populate the return table (bapiret2) of any of our AIF actions and display there the message ID.

 

If we need to get the control record we can do that using the function /AIF/IDOC_CONVERT_SAP_STRUCT

or you can do get it from the raw structure itself as per my article: Michal's tips: Application Interface Framework (AIF) - IDOC processing with AIF actions

For the purpose of the exercise I will show how to map the raw structure to the IDOC structures again and put in the message ID in the AIF log.

 

 

Code listing

 

*convert the RAW IDOC data to IDOC data again

CALL FUNCTION '/AIF/IDOC_CONVERT_SAP_STRUCT'

  EXPORTING

    SAP_STRUCT        =  LR_REF

    IV_TYPENAME       = 'ZAIFFLIGHTBOOKING_CANCEL01'

IMPORTING

   ES_EDIDC          =  LS_IDOC_CONTRL

   ET_EDIDD          =  LT_IDOC_DATA

          .

 

 

*use helper class to put the data to the log an return in the return_tab structure

CALL FUNCTION '/AIF/UTIL_ADD_MSG'

  EXPORTING

    MSGTY                     = 'I'

    MSGID                     = '/AIF/MES'

    MSGNO                     = '000'

    MSGV1                     =  'PI/PO message_ID is'

    MSGV2                     = LS_IDOC_CONTRL-arckey+20(40)

    MSGV3                     = ' idea by Michal Krawczyk'

  TABLES

    RETURN_TAB                = RETURN_TAB

          .

IF SY-SUBRC <> 0.

* Implement suitable error handling here

ENDIF.

 

 

 

Now when you run the scenario via AIF you should be able to see the PO/PI's message ID in the AIF log as shown on the Figure below.

 

 

idoc_mess_id.png

As some of you may now it's possible to call transactions and reports with data from the message variables within the AIF Monitor and Error Handling transaction (/AIF/ERR). Nicole Goeddelmann has also shown a way on how to call AIF value mappings in her recent article but what if we'd like to call a custom mapping table and to check some of the values ? If there a simple way ? It turns out it's not that difficult, you just need to follow the steps shown in my article.

 

Step 1

 

At first you need to have a custom mapping table like the one shown below for example.

 

pic1.png

 

 

Step 2

 

If you open your custom mapping table in SE16 you can get the generated program name - /1BCDWB/DBZAIFDEMO

 

pic2.png

 

 

Step 3

 

In order to pass the variables from the system message from transaction /AIF/ERR to the selection screen of custom table we need to write a small program which will open the selection screen at a predefined row of the table.

 


REPORT  Z_KRAWCZYK_AIF_2.

 

DATA : lt_key TYPE table of RSPARAMS.

DATA : ls_key TYPE RSPARAMS.

 

*we will take one parameter from the /AIF/ERR as input (and this is the key field in our customizing table)

 

Parameters: p_key type char10.

 

ls_key-SELNAME = 'I1'.

ls_key-kind = 'S'.

ls_key-sign = 'I'.

ls_key-option = 'EQ'.

ls_key-low = p_key.

ls_key-high = p_key.

insert ls_key into table lt_key.

 

*we call the module which will display the table entry for a specific key 

 

CALL FUNCTION 'RS_TABLE_LIST_CREATE'

  EXPORTING

    TABLE_NAME               = 'ZAIFDEMO'

  TABLES

    SELTAB                   = lt_key

          .

IF SY-SUBRC <> 0.

* Implement suitable error handling here

ENDIF.

 

 

Step 4

 

Now we can assign the report to the error message in /AIF/ERR and assign the variable to the input parameters of the report.

Please make sure you also select the checkbox - "Skip first screen"

 

pic3.png

 

 

Step 5

 

 

From that time whenever we try to select the function for the error message as shown on the picture below

 

pic4.png

 

system will take us automatically to the table display of the custom mapping table where you can check if the value exists.

 

 

pic5.png

 

 

Note:

 

You can use this functionality not only to display the whole key of the table but only the part which might be missing as if they key does not exist system will not take you anywhere.

A typical authorization case in interface monitoring is that you need to restrict access to some interface for some users. This is a standard case and it can be easily implemented within proxy monitor too just like shown in one of my previous articles SXMB_MONI - controlling access to message display

What if there's a need to do the same on the content of a particular message? Imagine that business guys from one plant should not be able to view the interface data from another plant and vice versa and both are using the same interface. Such autorization is not possible within the standard proxy monitor - SXMB_MONI (nor in IDOC monitor - WE02/WE05) but this is where SAP AIF comes into place. With SAP AIF it's not only possible to do searching on the basis of the content of messages (using index tables) but it's also possible to implement authorization concept on the basic of content of messages.

 

 

Let's imagine we have a message like shown below which has two fields inside (Airline ID and Booking number).

 

picture1.png

 

We have implemented a search on indexed table for the airline ID field (just like shown in my article - Michal's tips: Application Interface Framework (AIF) - IDOC with custom selection criteria (index tables) so you can see that the messages are grouped according to the airline ID.

 

picture2.png

 

Now we'd like to make sure that the user is only able to view message data if the airline ID = AA and will not be able to display in case airline ID is different than AA. In order to achive that we need to do a few things as shown below.

 

 

Step 1

 

 

At first we need to create a new authorization object in transaction SU21. Create a new authorization object with class - AIF and two fields. One ACTVT (mandatory field) and with the field which is the same as your key field from the message - airline ID (same with carrid in my case). In case the authorization field is not available you can simply create a new one.

 

picture3.png

 

 

Step 2

 

 

For authorization field ACTVT you need to add some permitted actitivities which will define the what you can do with the message (like read, change, etc.). This is the list of the mandatory activities for this field:

 

 

picture4.png

 

 

 

Step 3

 

 

In the next step you need to add your authorization object to the role which will be assigned to the user who will be responsible for monitoring. You need to do that in transaction PCFG. You can either create a new role or update any of the existing roles. Once you add the authorization object to the role you will be able to select the properties for the authorizations fields.

 

 

picture5.png

 

 

Select all activities for field ACTVT.

Select AA airline ID in the carrid field (so user will only be able to view data when airline ID = AA).

 

picture6.png

 

 

Now you need to save and generate the role and then you can add it to your monitoring user. 

 

 

 

Step 4

 

 

The last step you need to do is to assign the authorization object to the AIF interface in transaction - /AIF/CUST - Error Handling - Interface Specific Features.

 

picture7.png

 

and then you need to assign the the authorization field to the key field defined for the AIF interface.

 

picture8.png

 

 

 

Step 5

 

 

Now when you open AIF monitoring transaction you will only see the message for airline ID = AA and nothing more.

 

picture9.png

 

 

 

I hope this short introduction to the AIF authorizations will let you design similar authorizations in your landscapes.

SAP Application Interface framework (AIF) is too good a solution for building business friendly interfaces.

It is so developer friendly and SAP centric that there is a chance that development teams could possibly

miss the bigger premise of EAI and middleware/ESB centric integration patterns or solutions altogether

while developing interfaces using AIF.

 

Performing the translation from raw data structure (inbound interfaces) to SAP structure on the destination

SAP system along with any checks, value mappings and finally calling actions to perform the business logic

is the main concept behind AIF. This is perfect for point-to-point interfaces (one source and one receiver and

one of the two being a SAP system).

 

However, not all interfaces are point-to-point. Numerous integration scenarios are in use which employ various

EAI patterns like Canonical data model or Content based routing etc. For instance, in a Canonical data model,

there is an intermediary structure or Canonical data model. Although we are using AIF, the complete end-to-end

Integration pattern should still be preserved and we should not be building a solution with point-to-point interfaces

using Interface Variants etc. in AIF. What could be a possible solution here is that the Canonical data model

becomes the raw data structure and the translation in AIF framework is from Canonical data structure to SAP structure.

 

Other Integration Patterns like Content Enrichment (in our case, say lookups are only required from destination

SAP System), Content Filter, and Message Translator etc are good cases where AIF can take over the functionality

what was previously accomplished in Middleware. To conclude, while designing interfaces using AIF and leveraging

the numerous features available in AIF, we should take a step back and see if the end-to-end integration pattern is still being preserved and we are staying away from the easy tendency to create multiple point-to-point interfaces in place of an original EAI Integration Pattern or solution.

In this blog I would like to show you how you can get your first impressions of the SAP Application Interface Framework 2.0 right after installation. With the SAP Application Interface Framework an example of an interface creating flight bookings is delivered. This interface is using the runtime and persistence of the SAP Application Interface Framework.

 

Prerequisites:

  • Make sure that you have completed the post-installation steps.
    • Transport the delivered default customizing into target client. This is necessary since the default customizing will only be available in client 000.
    • Generate number ranges with report /AIF/GENERATE_NUMBER_RANGE
  • Since the interface is using the flight model, you should check that enough valid data exists in your system. In case there is no data, the flights are out-of-date, or all flights are fully booked you can use transaction BC_DATA_GEN to (re-)generate data.

 

Process Data:

Access the customizing for the SAP Application Interface Framework by calling transaction /AIF/CUST and go to customizing activity Interface Development->Define Interfaces and insert Namespace /AIF/. An interface FLBOOKING with interface version 1 should be displayed.

AIF_FLBOOKING_1_Intereface.png

 

To send test data to this interface call transaction /AIF/PERS_TEST. You can use the default entries of the screen to process data with interface /AIF//FLBOOKING/1. Click the execute button to sent data.

 

Monitoring and Error Handling

After the data has been processed you should be able to see the data messages in Monitoring and Error Handling. Call transaction /AIF/ERR and select namespace /AIF/, interface name FLBOOKING and version 1. In the status selection click Select All button. Click Execute.

The data messages you just processed should be selected and displayed in the Monitoring and Error Handling. You can expand the tree in Data Messages view to display the single messages. Note that the messages will be grouped by airline ID, since an interface specific key field was customized. When you select one or multiple messages the structure of the message will be displayed in Data Structure view. Furthermore, the log messages written during processing of the data message will be displayed in Log Messages view. If you double click structure BOOKING in Data Structure view, the content of the selected data message(s) will be loaded into Data Content view. Below you can have a look at the layout of the Monitoring and Error Handling transaction.

ErrorHandlingLayout.png

If errors occured during processing of some messages you can try to restart and cancel those messages.

 

Interface Specific Selection Screen

If you restart transaction /AIF/ERR and insert interface /AIF//FLBOOKING/1 on the selection screen you will realize that an additional sub-selection screen will be displayed. This sub-selection screen is specific for the selected interface. You can use the sub-selection screen to restrict the data messages that should be selected. For example, if you enter Airline "LH" only the flight bookings for Lufthansa flights should be selected.

You are wondering about how to set up interfaces with the SAP Application Interface Framework? Or you want to know how you can make use of the new features of the SAP Application Interface Framework 2.0? Then you have found the right place to look for this kind of information.

 

In this space we will provide useful information for interface developers and everyone else who wants to facilitate implementing interfaces, monitoring and error handling with the SAP Application Interface Framework.

 

In case you are business user, don't run away. You are also very welcome to have a look into this space. You will also find usefull hints here on how to do monitoring and error handling with the SAP Application Interface Framework.

 

First of all I'd like to give a short overview of what the SAP Application Interface Framework is:

The SAP Application Interface Framework is an add-on that provides you with a structured way to implement your interfaces. An interface consists of different interface building blocks, for example value mappings, actions and checks. The SAP Application Interface Framework does not only support you in implementing interfaces, you are also able to do monitoring and error handling. Actually, the monitoring and error handling of the SAP Application Interface Framework is targeted at business users. They usually know best how to solve functional errors that occurred during processing of a message. Since the SAP Application Interface Framework supports multiple interface technologies, monitoring and error handling can be done in the same transaction independent of the technology used for processing the message.

 

If you want to develop an interface with the SAP Application Interface Framework the best place to get information is the Cookbook. Within the cookbook all customizing activities are described, that are needed for defining an interface in the SAP Application Interface Framework.

 

The SAP Application Interface Framework 2.0 offers additional features, that are not described in the cookbook. For now I'd like to give you a short overview.  A description of how you can make use of those new features will be available soon in this topic space.

  • Monitoring and Error Handling for IDocs: For integrating your IDocs with the SAP Application Interface Framework four different scenarios exists:
    • Monitor existing IDocs
    • Process IDocs with SAP Application Interface Framework and call IDoc function in action
    • Process IDocs with SAP Application Interface Framework and call BAPI or any other function in action
    • Use the Enabler for IDocs to create index table entries and alerts
  • Persistence and Runtime of the SAP Application Interface Framework: With the SAP Application Interface Framework an own persistence and runtime is delivered that offers a fast and parallel message processing
  • Enabler: The Enabler allows you to monitor existing interfaces with the SAP Application Interface Framework without much effort. You can make use of functionalities like index tables, interface specific selection screens and alerting.
  • Integration of Error and Conflict Handler: The SAP Application Interface Framework offers you the possibility to monitor ECH interfaces (e.g. asynchronous SAP Enterprise Services). Vice versa it is also possible to monitor interfaces of the SAP Application Interface Framework in ECH (note: this is only possible if you have NetWeaver 7.31 and AIFX installed).
  • SIW template: A template for the Service Implementation Workbench is delivered that allows you to generate interfaces for the SAP Application Interface Framework (note: this is only possible if you have NetWeaver 7.31 and AIFX installed).
  • Web Application for Monitoring and Error Handling (note: to use the Web Application it is necessary that you use NetWeaver 7.31 and AIFX is installed)
  • Custom Specific Engines: In order to support different interface technologies different engines are delivered with the SAP Application Interface Framework. If the engines delivered do not fit your requirements it is also possible to create your own customer specific engines.

Actions

Filter Blog

By author: By date:
By tag: