🚀欢迎来到本文🚀
🍉个人简介:matinal,目前职业是IT行业,一个正在慢慢前行的普通人。
🏀系列专栏:涵盖SAP各模块,Python,Excel,人工智能等
💡 其他专栏:一些平时学习的技术,感兴趣的小伙伴可以看看。🍔公众号:matinal
🎁希望各位→点赞👍 + 收藏⭐️ + 留言📝
⛱️万物从心起,心动则万物动🏄♂️
前言:BAPI Introduction
🦙(工作遇到傻逼,千万要远离。道路千万条,远离傻逼第一条)
Distribution Using BAPIs
BAPIs can be called by applications synchronously or asynchronously. ALE functions such as BAPI maintenance in the distribution model and receiver determination can be used for both types of call.
Note that synchronously-called BAPIs are only used for reading external data to avoid database inconsistencies arising from communication errors.
The application synchronously calls a BAPI in the external system to create an FI document. The document is correctly created but the network crashes whilst the BAPI is being executed. An error message is returned to the application and the FI document is created again. The document has been duplicated in the system called.
An application program can implement a two-phase commit by thoroughly checking the data in the external system. An easier solution is to call the BAPI asynchronously, as Error Handling assures that the data remains consistent.
A BAPI should be implemented as an asynchronous interface, if one of the criteria below applies:
- Consistent database changes in both systems
Data must be updated in the local system as well as on a remote system
- Loose coupling
An asynchronous interface would represent too narrow a coupling between the client and the server systems. If the connection fails the client system can no longer function correctly.
- Performance load
The interface is used often or it handles large volumes of data. A synchronous interface cannot be used in this situation because performance would be too low.
If you want to implement a BAPI as an asynchronous interface, you have to generate a BAPI-ALE interface for an existing BAPI. For more information see Generating BAPI-ALE Interfaces.
Data distribution using BAPIs is illustrated in the graphic below:
The processes in the application layer and the ALE layer are completed on both the inbound and outbound processing sides. The communication layer transfers the data by transactional Remote Function Call (tRFC) or by EDI file interface.
The process can be divided into the following sub-processes:
1. Outbound Processing
- Receiver determination
- Calling the generated outbound function module
- Conversion of BAPI call into IDoc
- Segment filtering
- Field conversion
- IDoc version change
- Dispatch control
2. IDoc dispatch
IDocs are sent in the communication layer by transactional Remote Function Call (tRFC) or by other file interfaces (for example, EDI).
tRFC guarantees that the data is transferred once only.
3. Inbound Processing
- Segment filtering
- Field conversion
- Transfer control
- Conversion of IDoc into BAPI call
- BAP

222

被折叠的 条评论
为什么被折叠?



