Connector for SAP Business Suite - API description - Developer's manual part 1 - Overview
This documentation contains the description of the SAP Portal Plugin (codename "SAPPOPI") that was developed for connecting SAP and Intrexx. The SAP Portal Plugin consists of developments with framework character in the customer namespace, which could also be used for other portal projects and/or interfaces with external systems. This documentation is primarily aimed at SAP developers who would like to provide SAP data to Intrexx or any other external system.
Please visit www.intrexx.com to find the current terms of service for the SAP Portal Plugin. SAP customers are allowed to use the functions on the SAP-side in their own projects, provided that no third-party integrates their own commercial solutions or products into SAP systems using the SAP Portal Plugin. The SAP Portal Plugin is maintained on a voluntary basis. No liability is assumed for damages caused whilst using the SAP Portal Plugin.
1. Conceptual approach
All Intrexx data groups possess a key field (field name "LID"), this has the integer data type in all portal-internal tables. Intrexx supports the user in setting up subordinate data groups (dependent data) and references. The following applies: Subordinate data groups contained an individual and unique key and the key of the parent data set (e.g. "FKLID" and "LID"). In Intrexx applications, data from external applications can be integrated, as long as this is provided in tabular form. These external data groups come from a data source (or database connection) and can be integrated into the applications without the user having to worry too much about the technical parameters. The only limitation is that the external data field must contain a field that contains a unique identifier for the data record. The technical data type is not prescribed in this case.
The data source, which can be set up in the Intrexx Portal Manager (Integration module), contains information about the type (e.g. "JDBC" or "SAP") and the technical parameters required in each case (e.g. connection parameters, login information).
If you're planning on integrating an external system such as SAP, this data-group-oriented approach determines the design of a special connector. Most of the information can be displayed as a table and is therefore suitable. Even SAP Reports (SE38 program) can be technically presented as a virtual table where output rows are viewed as text and the output of the table is created using the individual output rows. From the portal side, this means it's necessary to introduce another term - the datahandler. In this way, a data source could be the technical table access of ZKUNDEN in SAP R/3 Test. That being said, access can also take place to the report with the same name, ZKUNDEN. The datahandler therefore determines the type of access and the table used for the technical implementation. Every data group can therefore be defined uniquely using the following combination:
Database connection or data source
Datahandler or access type
Table or object name
2. Expansion concept: Intrexx
Intrexx standard is already capable of realizing a large amount of the requirements on portal applications, such as changes to the user interface, new fields or changes to the process. Only special testing logics, complex requirements on the business logic or the integration of external systems, require, where necessary, the path of expansion. Intrexx provides three fundamental options for expansion:
Java expansions (Velocity) Intrexx is built on a Java framework. In this framework, individual Java classes can be integrated, these implement reusable functions or realize special presentations on the surface.
Unique business logic handler Certain portal functions are implemented using business logic handlers, these are implemented in Java. Data group actions are, for example, are dealt with using these handlers.
When incorporating external data as an Intrexx data group, unique data group handler classes need to be developed. This approach has been selected for integrating SAP systems.
This unique handler for the SAP access has to implement the following API methods:
Get_Meta_Information Technical information about the data object (e.g. field names and technical data types)
Parse_Data_Range Data record selection restricted by filters and where appropriate sorted and with offset access (e.g. 20 data records after the 100th)
Parse_Data_Record Detailed information about a certain data record
Modify_Record Insert, change or delete data records
The technical method names vary from the actual names but are predefined using inheritance.
3. SAP data sources
The communication of SAP systems between themselves, as well as exchanging information with application components, tools or many external products, are implemented using the RFC technology. This method is well-engineered and is available for most platforms as well as for most programming languages. The SAP Java Connector has been available to the Java world for years, this is used both by the individual Java-based solutions as well as stand-alone. Using the SAP Java Connector and the RFC interface stands to reason because Intrexx portals are entirely based on Java.
4. Finding concept
The following figure demonstrates the finding of technical systems from the external data groups.
Especially the data source is used within the portal in order to determine the actual target (technical parameter). The datahandler and table name are mainly used in the called up system so that the correct processing routines are called up.