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.
Conceptual approach
All Intrexx data groups have a key field (field name "STRID"), which has the data type "String" in all portal-internal tables. Intrexx supports the user in setting up subordinate data groups (dependent data) and references. The following applies again: Sub-data groups contain their own unique key and the key of the parent data record (e.g. "FKSTRID" and "STRID"). Data from external applications can be integrated into Intrexx applications as long as they are available in table 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 respective required technical parameters (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 is 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
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:
-
JavaScript
This allows you to primarily implement simple verifications, reactions to events or showing and hiding fields based on status information. JavaScript is integrated into the graphical tools of the Portal Manager, but is considered to be one of the expert functions.
-
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.
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.
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.
More information
SAP Trust Manager SSO configuration
API description Part 2 - SAP Portal Plugin
API description Part 3 - Implementing custom processing modules
API description Part 4 - Sample coding
Developer's Manual Part 2 - Integration scenario, SAP external data group
Developer's Manual Part 3 - Scripting integration scenario
Developer's Manual Part 4 - Personalized SAP Access / Single Sign On (SSO)
Email us