MySAP has evolved a lot over the years and started using cutting edge technologies like RFC,BAPI,IDOC and ALE.Here in this post we are going to discuss what are the definition and meaning of this SAP technology terms and how they are used and implemented with respect to each update.This is only the beginning of the series that we are discussing about the details of this new generation ERP technology and this way of discussion will be further continued in the coming time.
mySAP Technology is the naming standard that SAP uses for all the applied sciences produced by SAP.SAP Enterprise Framework is the structure that SAP put in place for supporting seamless integration of components. This makes it completely suited to creating a set of built-in merchandise from SAP products that could be installed, managed, and upgraded independently without affecting different systems’ components.
Business Framework was technically supported on integration applied sciences such as BAPIs and ALE, plus the underlying technology of the stable R/three multitier client/server structure, the standard communication protocol comparable to CPI-C (Widespread Programming Interface-Communication) and RFC (Remote Function Calls), the openness and independence of a hardware platform, or the portability of the purposes based on the ABAP (Superior Business Application Programming) language.
Enterprise Framework structure was based mostly on the technological ideas of parts, interfaces, and integration.
1. The elements would supply the business functionality. So for instance, the logistic purposes, the Business Information Warehouse, the Business to Enterprise Procurement, and a lot of different functions might be considered elements, which might integrate among themselves by using standard interfaces.
2. The interfaces, mainly based mostly on BAPIs, provided the communication technology, based mostly on enterprise objects, that might be used for connection and information change among the business components.
3. Integration technologies had been supplied via ALE and others, like the SAP Business Workflow. The aim of those applied sciences was to guarantee the integration of the enterprise processes amongst completely different components.
The evolution of the Business Framework toward Web standards and Internet-based mostly purposes launched the Internet Enterprise Framework, which, as has been said several instances, can be thought of the technological basis of the mySAP.com platform.
The truth that the client/server technology of the classical R/three techniques is nonetheless in place must be highlighted; the dispatcher and work processes are still behaving with the identical technical benefits and strong architecture that made R/three such a superb software program system. It has been quite developed and enhanced, with new process architecture, new memory management, and support for protocols akin to HTTP or the flexibility to interpret JavaScript directly. The next sections provide an summary of the classic features and technical characteristics of R/three systems, lots of that are current in the mySAP e-enterprise platforms.
Client/Server Basis
Client/server is a software idea that first appeared within the late ’80s, but was deployed seriously and with a solid technical foundation in the early and mid ’90s. As a software idea, it included service providers (servers) and repair requesters (clients). A particular program could act as supplier and requester on the similar time. So as an illustration, the SAP R/three typical application server was a service supplier for the customers (SAPGUI) but was a service requester of the database server.
The principle point of any such computing was the separation of the person-oriented tasks, and the execution of software tasks and the information management tasks. These three varieties of tasks are usually matched with the terms presentation, application, and data levels.
With client/server computing, it was doable and easier to distribute the workload of computer functions amongst totally different and cooperating laptop packages or processes. From the very beginning, SAP R/three systems had been designed this way so that there was a presentation stage (user interface or presentation server), an application stage (utility server), and a database level (database server). The software providers supplied by client/server computing would communicate amongst them utilizing predefined interfaces over customary communication protocols, for instance, remote SQL calls from the applying server to the database server over TCP/IP.
With the emergence of the Net, the power to have a simple Web browser as the person interface, and the development of ITS again in 1996, the basic threetiered shopper/server architecture became a multitier system.
The classic three-stage or multilevel client/server configurations provided a collection of benefits which are nonetheless available in mySAP system environments, resembling:
1. Environment friendly distribution of workload. As a consequence of software servers work in parallel and communicate with the database, utility duties will be simply distributed.With R/three methods, it was additionally widespread to search out installations where a quantity of application servers had been devoted to particular tasks, similar to background or printing.
2. Flexible configurations. Client/server architectures offer many different ways of installing, distributing, or upgrading a system landscape. Within the mySAP.com age, this flexibility has even been increased, with the ability to have a quantity of totally different mySAP parts with several databases in a single server.
3. Excessive scalability. With client/server architectures, it is fairly straightforward to enhance or adapt the facility capability of the methods in response to the changing needs of the business. So as an illustration, when the number of customers or the load of the purposes will increase, it's fairly simple to install extra utility servers with out the want to cease the systems.
RFC: A Key Communication Middleware
RFC, Remote Function Calls, is the usual programming interface lengthy utilized by SAP for making distant calls among packages situated on the identical or on completely different systems. Which means that a perform that's developed in a single system could probably be remotely called by one other program. R/three has a function library the place programmers can find helpful subroutines to reuse in their ABAP programs. This library has the function modules organized in teams like arithmetic features, character string manipulation features, controlling functions, and so on. You may entry this perform library from the operate builder transaction SE37. These functions, in addition to every of the interface parameters, will be documented, serving to the programmer to grasp how you can name these features from ABAP.
Since launch 2.zero, SAP R/3 helps RFC in order to have the power to call a operate module from one other R/three system, from an R/2 system, or from exterior systems. This was a key issue in the current Enterprise Framework strategy. The first sorts of RFC were synchronous RFC, permitting a program to name a operate in another R/3 system and get the outcomes online.
SAP provided libraries for non-SAP environments in an effort to call these function modules, like C and C++ libraries, in the supported SAP working systems, including Windows, UNIX, Linux, OS/390, or OS/400. There has also been support for DLL (Dynamic Hyperlink Library) and ActiveX in Home windows or Java RFC. For transactional environments, SAP developed the tRFC (transactional RFC) in release 3.0. On this case, this system calls the remote function, and the system guarantees the supply of the call, recalls in the case the associate system shouldn't be accessible, and assures that the function is executed solely once. tRFC is asynchronous, but if the accomplice system is available, it's executed as soon as possible.
With release 4.6B, a model new extension of tRFC was made, and it was called qRFC (queued RFC) in an effort to outline an order and “queue” the calls which would possibly be executed one after the other. The queue might be in the supply or within the target system. This qRFC may be downloaded to variations 3.1I of R/3.
BAPI
With release 3.zero, SAP began the object-oriented approach. From that launch, there is a Business Object Repository containing the SAP Enterprise Objects, like a purchase order order or a customer. These Enterprise Objects have attributes or properties and methods like Create, Release, and others, relying on the item type. The methods of the Business Objects are applied mainly as operate modules,so they can be known as in an object-oriented view or immediately like function modules.
A few of these strategies have been flagged by SAP as stable methods. This implies that SAP guarantees that the method interface (export - import - Tables parameters) won't change in two major SAP releases. These secure methods are referred to as BAPIs. BAPIs had been announced for normal availability in release 3.1G.
There are greater than 1,a hundred BAPIs in release 4.6. SAP has published the BAPI allowing the developer group to develop exterior programs with a guarantee within the growing funding, as a consequence of this system will work even when the client changes the SAP release. These BAPIs have been also utilized by SAP internally to develop preliminary load packages sooner than the old batch input methodology and to integrate the different SAP functions with these BAPI calls.
IDOCs
IDOC (intermediate documents) historical past is related to the EDI (Digital Information Interchange) interface. EDI was one of many first efforts to define a flat text format for business documents, like invoices or gross sales orders, in order that they could possibly be exchanged between methods and applications. SAP supported EDI from the very starting, since launch 2.0. The key drawback in supporting EDI was that truly there are several substandards in EDI, like EDIFACT, ANSI X-12, ODETTE, and others (Europe, America, Vehicle Industries), and there is the necessity for translating your internal paperwork to the substandard your companion speaks. In an effort to assist this, SAP defined its own commonplace representation of the doc, often identified as IDOCs. Then the customer can choose licensed software program that understands the IDOC format and interprets it to the chosen EDI substandard, which can be in command of sending and receiving the IDOCs.
At first, SAP defined IDOCs primarily for the type of documents utilized in EDI. Then SAP realized that these IDOCs may very effectively be used straight if the partner system was one other SAP system. It began to make use of IDOCs to send and obtain documents between SAP systems as well. IDOCs from older releases could be interpreted by newer SAP releases, and new releases can adapt the IDOC release, relying on the target system. This was the foundation of ALE.
ALE
The thought behind ALE was to have the flexibility to combine purposes in different SAP or non-SAP methods in a loosely coupled way.This could presumably be helpful for different reasons. Some large organizations have subsidiaries on different continents, and maybe it makes little sense for assist reasons to have the R/three system for the plant in Singapore within the U.S. headquarters. It could presumably be helpful from the community viewpoint; the users connected inexpensively to their system in Singapore fairly than by costly strains to the central system with the bandwidth required for an internet user. Different reasons are organizational reasons (in some circumstances the offices are almost autonomous enterprise models) or even performance causes to be able to distribute the load.
That is why SAP developed the ALE inside R/3. With ALE, you possibly can outline which systems participate in your ALE community (in the ALE world, a system is an exterior system or a consumer of an R/three system) and which knowledge should be despatched from one system to the others. In ALE, it is doable to distribute master information (prospects, materials), doc data (purchase orders, financial paperwork, invoices), and in addition customizing information (entries in selected customizing tables).
In the case of distributing grasp data, you may, for example, outline one system where you centrally keep the materials and then distribute the creation or adjustments to the other systems. But the data distribution also could be outlined with ranges and filters, for example, to define centrally some supplies but enable the vegetation to have their own vary for internal use, or even outline a bidirectional upkeep (adjustments in any system are replicated to the opposite). This is defined within the ALE model.
ALE started utilizing IDOCs with a view to ship and obtain paperwork between systems (SAP or non-SAP). In the case of SAP programs, the IDOCs are despatched often by tRFC to the opposite system. If the associate is a non-SAP system, an IDOC translator that understands IDOCs and speaks with the other system can be used, as can file or CPIC interfaces.
When the BAPIs appeared, the ALE also included BAPIs for the new scenarios. For example, the Central User Administration scenario uses only BAPIs to alternate the consumer definition and roles between R/three systems. Now that is used between mySAP components.
ALE is the inspiration for what SAP calls the Business Framework. At first, the ALE eventualities allowed integration between the completely different logical methods in the ALE community, but not the entire integration if all of the elements had been in one central system. You want to take a look at each scenario’s documentation to know which restrictions apply compared to a central system. The primary full software that was decoupled was the HR (Human Assets) module.With HR, all the attainable interfaces between HR and the completely different purposes had been supported in ALE. On this way, it’s possible to have a system with the HR module integrated with different SAP systems.
One of many advantages of this approach is you can change the discharge of one of many parts of the Enterprise Framework without changing the release of the others. Perhaps the client wants the brand new launch for the HR module due to legal causes, however can keep the financial system in the same launch with out involving the FI (Financials) people in the upgrade project. Within the case of HR, this has different advantages, like improved safety in a remoted system.
ALE makes use of workflow for error decision and has tools for supporting a number of restore situations and methods synchronization. With mySAP, the Business Framework and its Web evolution is used even more than before. With mySAP CRM, e-procurement (BBP), APO (Advanced Planner and Optimizer), Strategic Enterprise Management (SEM), and other systems built-in between them and the R/3 again ends, it is possible to alter the release of considered one of them without disturbing the others.
Related Posts:
Business warehouse information and reporting overview
SAP BW information and reporting tools
SAP business scenario for material planning
No comments :
Post a Comment