External collaboration needs to allow data access from the internet. In a trusted internet collaboration scenario where the external user works on the same data like the internal user (and not on copies) direct access to the data in the intranet is required.
This requires special and strong security mechanism:
- No direct access from the internet to the system in the intranet is allowed
- Provide a protocol change between request and data access
A solution for this requirement is to separate UI and data in a way that there is no need to offer direct access to intranet.
In the DMZ scenario the presentation layer (UI) is running on a system in the DMZ (demilitarized zone) network area which is separated from the system in the intranet where the data is stored. Therefore all data (with a few exceptions) needs to be accessed via RFC function modules. This allows a controlled access to the backend data and avoids a duplication of data needed for external collaboration.
Additional security mechanism may be needed (e.g. specialized collaboration UIs; more detailed authorization in the coding; Access control to the DMZ network area (e.g. using IP filter ..) but they are not focused by this chapter.
The DMZ scenario is supported by the SPI out of the box without the need of additional application specific logic.
The Generic Service Provider and the RFC Connector are accessed internally by SPI and are normally not relevant for application development. The Generic Service Provider serves as proxy for the Connector to instrument the RFC Connector in the DMZ system. The RFC Connector itself is responsible to execute the RFC call to the backend system where the request is forwarded to the Connector again.
The RFC enablement of the data access is a technical base to support a separate UI system in the DMZ.
This chapter is about the setup of the RFC connection as well as the services that can be used to implement the DMZ enablement.
Main rules are
- Both systems should have the same version of software (same components, switches and correction transports)
Customizing which controls business logic normally only needed in the backend system.
Exceptions: Customizing from reuse components may have to be duplicated in the DMZ system like "Units of measure" (Units are displayed using a Conversion Exit)
Customizing Access Needs to be DMZ Enabled
Ensure to read customizing, which is needed in the UI, always from the backend system (as part of the application data or e.g. with the table provider (see class /PLMB/CL_FRW_TABLE_PROVIDER)
- Navigation (e.g. call transaction) to non DMZ-enabled UIs are forbidden (different security settings expected)
User data and a few Customizing Settings (Output Formatting, RFC Connections, Language ...) are needed in the DMZ system. Everything else has to be retrieved from the backend system by RFC.
To test the DMZ scenario internally an additional client representing the DMZ system is sufficient.
For real tests with external partners a real DMZ system in the real SAP DMZ area is needed:
- A Security Concept which documents all accesses and connections (protocols and ports) crossing the firewalls has to be approved by network security responsible (Security from SAP Hosting FAQ.
- The DMZ system needs to be connected to the development system landscape to get all transport.
- The user ID in the DMZ system must be identical to the user ID in the intranet system.
- The authorizations for the user in the DMZ system can be reduced to a minimum to increase security.
Settings needed in the Backend system
Use transaction SMT1 (or SM59 "Extras" -> 'Trusted Systems') to setup a trusted connection to the DMZ system.
The logon from DMZ system to the Backend system is carried out using the same user name in both systems.
Trusted System Connection
More insight how to establish a trusted system connection for DMZ system (client, trusted system) and backend system (server, trusting system):
Note 128447 – Trusted/trusting systems
- Maintain the authorization object S_RFCACL: the field "RFC_EQUSER" must set to Y (for YES).
- Maintain the authorization object S_RFC: Give user access to the function groups /PLMB/RFC_CONNECTOR, /PLMB/SPI_RFC and /PLMB/SPI_SHLP.
Customizing the RFC connection in the DMZ system
Setup the RFC connection using SM59
- Use transaction SM59 to set up a Remote Function Call (RFC) connection from the DMZ system to the backend system.
- Setup a trusted RFC connection with named users. Do not use a technical User like ALEREMOTE for this RFC connection!
Choose the following settings
<Backend System Name>CLNT<client> (e.g. Q35CLNT002_logon_user)
3 (Connection to SAP R/3)
Technical Settings tab page
<target host name> (e.g. /H/184.108.40.206/H/q35main.wdf.sap.corp)
Logon/Security tab page
Important: Leave this field empty!
<client> (Client which has the data, e.g. 002)
Important: Leave this field empty!
Enter the following string: "is initial"
- Save your RFC destination and go back to the RFC Overview screen.
- In the RFC Overview screen choose from the menu bar "Extras" -> "Trusted Systems" (or Transaction SMT1) and add the system name of the backend system as "Trusted System".
Register the RFC Destination as Backend for the DMZ System
Enter the RFC connection in the Customizing of the DMZ system (table /PLMB/RFC_DEST) IMG-Path:
Cross-Application Components -> Processes and Tools for Enterprise Applications -> Settings for BO Framework and Navigation -> BO Framework -> Define RFC Destinations.
Customizing of DMZ System
Overview which customizing is needed in the DMZ system:
Note 1413474 – Settings of a DMZ system for the PLM Web User Interface
Limitations of the DMZ Scenario
Attributes with references to backend data can't be handled in a DMZ scenario:
- Object references to instances existing in the backend
- URLs (e.g. for Icons) generated on the backend
Attention: References will work in a one system scenario.
DMZ needs own tests!
The SPI is designed for accessing BO-like Data with CRUD services (Create, read, update and delete), but there are some use cases for data accessing which needs a different approach:
- DDIC Search help
- Conversion Exits
DMZ Enabled DDIC Search Help
The DMZ-enabled DDIC search helps are in principle a copy of the normal DDIC search helps, which has
- The search help exit /PLMB/SPI_SHLP_F4IF_GEN_EXIT
- An additional Search help parameter "IV_SHLP" which has as default the name of the normal DDIC search help
- Data elements which carry also DMZ-enabled DDIC Search helps
Collective Search Helps
When collective search helps are needed for the DMZ they need to be build up from elementary DMZ-enabled search helps.
The search help exit /PLMB/SPI_SHLP_F4IF_GEN_EXIT should also be added to the collective DMZ-enabled search help.
Limitations of DMZ Enabled Search Help
- DDIC Search helps with programmed UIs can't be DMZ enabled.
- packed numbers (e.g. timestamps) not supported (limitation of internally used FM BALW_SHLP_BAPI_FILL)
- help value limited to char255 (help values returned in structure BAPIF4C from BALW_SHLP_BAPI_FILL)
List of supported control search help parameter for the search help exit /PLMB/SPI_SHLP_F4IF_GEN_EXIT
Input Set at Runtime
Define the search help which should be processed (set as DEFAULT in apostrophes) max. length 19 (mandatory)
Define a 2. part search help name > 19 (length search help name <= 30)
Set 'X' if control step PRESEL1 should be performed (normally not needed!)
RFC Destination (not used for DMZ enablement)
LOGSYS (not used for DMZ enablement)
The search help exit /PLMB/SPI_SHLP_F4IF_GEN_EXIT allows the call of application own RFC logic (available with SAP_BS_FND 7.31):
- Own function modules if the source system has not SAP_BS_FND installed
- Own RFC determination) instead of the predefined logic
How To: the search help exit /PLMB/SPI_SHLP_F4IF_GEN_EXIT needs to be encapsulated by an own search help exit which has to provide an instance of a class which implements the Interface /PLMB/IF_SPI_SHLP_GEN_EXIT_RFC.
Remark: /PLMB/SPI_SHLP_F4IF_GEN_EXIT instantiates /PLMB/CL_SPI_SHLP_GEN_EXIT_RFC otherwise.
DMZ Enabled Conversion Exit
Conversion Exits in the DMZ system will not work if they need application data. All other Conversion Exits based on algorithm and/or customizing needs no change.
For example application data is needed if an internal key is mapped to a readable key within a Conversion Exit (e.g. MATN2 for long material number)
The class /PLMB/CL_SPI_CONVEXIT is used to handle this conversion on the backend.
This class has to be used as shown in the following code snippet in the Conversion Exit function modules at the very first statement (e.g. CONVERSION_EXIT_MATN2_OUTPUT):
For CONVERSION_EXIT_XXXXX_INPUT parameter IV_ACCESS needs to be set to /PLMB/CL_SPI_CONVEXIT=>GC_ACCESS_INPUT.
The conversion is stored in an internal buffer which can be filled upfront by using a mass enabled buffer fill method.
Methods of class /PLMB/CL_SPI_CONVEXIT
Get Instance of the Conversion Class (one Instance for one Conversion Exit)
Conversion Exit for Input or Output
Fill DMZ Buffer with mass access
DMZ Enabled Table Provider for Customizing
Customizing which is needed in the UI (e.g. for configuration) can simply be accessed with class /PLMB/CL_FRW_TABLE_PROVIDER.
Methods of class /PLMB/CL_FRW_TABLE_PROVIDER
Supply table names that should be read from database
Get table data
The names of tables which should be read by the table provider need to be populated in table /PLMB/FRW_TABPRO.
Limitations of Table Provider
Applications tables (delivery class A) are not allowed to be used with the table provider.
DMZ Enabled Classes
The Table Provider class as well as the Conversion Exit class using the class /PLMB/CL_RFC_CONNECTOR for the RFC call and they are implementing the Interface /PLMB/IF_RFC_CONNECTOR.
This mechanism can also be used for application specific needs where DMZ enablement is necessary but the additional services of the SPI are not needed.
An example for this use case is the DMZ enablement of the Business Context Viewer (BCV).
Therefore to DMZ enable a class it has to implement the interface /PLMB/IF_RFC_CONNECTOR which has one Method RFC_CALL_RECEIVE.
Within this method the application specific input parameters (exported with method RFC_CALL) can be imported. The requested result needs than to be exported and the export data is delivered back from Method RFC_CALL.
Remark: The data is exchanged by using the ABAP commands export and import. The format how the data is exported & imported has to be defined by the implementing class.
It is strong recommended that the caller method and the called method are implemented in the same class, to have the exchange protocol defined in only one class.
Methods of Class /PLMB/CL_RFC_CONNECTOR:
FM /PLMB/RFC_CONNECTOR is called and executes /PLMB/IF_RFC_CONNECTOR~RFC_CALL_RECEIVE in the backend
Get destination for remote function call
Check if current system is DMZ system
Check if called from DMZ system
Get Name of DMZ Application Server
Get IPv4 Address of DMZ Application Server
Example of Systems and Connections in DMZ Scenario
Content Server usage within DMZ
The access to the Content Server running in the intranet is not directly allowed. For this an additional Content Server in the DMZ area needs to be installed.
The DMZ Content Server is connected via ODBC to the intranet Content Server for a direct access to the documents.
Only Supported for Content Server running MaxDB
To setup a Content Server in the DMZ for SPI check note:
Note 1419452 – Setting for content server in PLM DMZ scenario
The Backend provides an URL which points to the intranet Content Server. This recalculation is done by using basis customizing settings.
Sample coding to regenerate a KPRO URL
Here a sample solution based on the basis customizing settings: