Page tree
Skip to end of metadata
Go to start of metadata

Introduction

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.

DMZ Scenario

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.

Comparison of One- and Two-System Scenario

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)

RFC Setup

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

  1. 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

  2. Maintain the authorization object S_RFCACL: the field "RFC_EQUSER" must set to Y (for YES).
  3. 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

  1. Use transaction SM59 to set up a Remote Function Call (RFC) connection from the DMZ system to the backend system.
    1. Setup a trusted RFC connection with named users. Do not use a technical User like ALEREMOTE for this RFC connection!
    2. Choose the following settings

      Attribute

      Setting

      RFC Destination

      <Backend System Name>CLNT<client> (e.g. Q35CLNT002_logon_user)

      Connection Type

      3 (Connection to SAP R/3)

      Technical Settings tab page

       

      Load Distribution

      Yes

      Target Host

      <target host name> (e.g. /H/194.39.131.37/H/q35main.wdf.sap.corp)

      Logon/Security tab page

       

      Trusted System

      Yes

      SNC

      Inactive

      Language

      Important: Leave this field empty!

      Client

      <client> (Client which has the data, e.g. 002)

      User

      Important: Leave this field empty!

      Password

      Enter the following string: "is initial"

      Current User

      selected

    3. Save your RFC destination and go back to the RFC Overview screen.
  2. 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

Services

All data accesses using the Service Provider Infrastructure are enabled for the DMZ scenario.

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
  • Customizing
  • ...

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

Control Parameter

Input Set at Runtime

Description

IV_SHLP

no

Define the search help which should be processed (set as DEFAULT in apostrophes) max. length 19 (mandatory)

IV_SHLP1

no

Define a 2. part search help name > 19 (length search help name <= 30)

IV_SET_PRESEL1

no

Set 'X' if control step PRESEL1 should be performed (normally not needed!)

IVI_SHLP_RFCDEST

yes

RFC Destination (not used for DMZ enablement)

IVI_SHLP_LOGSYS

yes

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):

FUNCTION conversion_exit_matn2_output.
*"----------------------------------------------------------------------
*"*"Local Interface:
*"  IMPORTING
*"     REFERENCE(INPUT)
*"  EXPORTING
*"     REFERENCE(OUTPUT)
*"----------------------------------------------------------------------

*Input is a MATNR field from table MARA. We need to convert it to the
*corresponding LMATN VERSN Kombination.
  DATA: mat_ext    TYPE matnr_ext, vers_ext TYPE matnr_ext,
        materialid LIKE materialid,
        itmp       TYPE i, olen TYPE i, slen TYPE i,
        lv_input_c(18).                                "SH note 1366176

**********************************************************************
* PLM 7.1 EhP5 : Handle LaMa for DMZ scenario
  DATA:
    lo_convexit   TYPE REF TO /plmb/cl_spi_convexit .

  IF /plmb/cl_rfc_connector=>is_dmz_system( ) = abap_true .

    CALL METHOD /plmb/cl_spi_convexit=>get_instance
      EXPORTING
        iv_convexit  = 'MATN2'
      IMPORTING
        eo_conv_exit = lo_convexit.

     CALL METHOD lo_convexit->convert
       EXPORTING
         iv_access   = /plmb/cl_spi_convexit=>gc_access_output
         iv_input    = input
       IMPORTING
         ev_output   = output.
     RETURN .

  ENDIF.
* End of PLM 7.1 EhP5 : Handle LaMa for DMZ scenario
**********************************************************************

  PERFORM setup_statics.
...

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

Method

Description

GET_INSTANCE

Get Instance of the Conversion Class (one Instance for one Conversion Exit)

CONVERT

Conversion Exit for Input or Output

FILL_BUFFER

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

Method

Description

REGISTER_TABLES

Supply table names that should be read from database

GET_TABLE_DATA

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:

Method

Description

RFC_CALL

FM /PLMB/RFC_CONNECTOR is called and executes /PLMB/IF_RFC_CONNECTOR~RFC_CALL_RECEIVE in the backend

GET_RFC_DESTINATION

Get destination for remote function call

IS_DMZ_SYSTEM

Check if current system is DMZ system

IS_CALLED_BY_DMZ

Check if called from DMZ system

GET_ROOT_DMZ_HOST_NAME

Get Name of DMZ Application Server

GET_ROOT_DMZ_IPV4ADDR

Get IPv4 Address of DMZ Application Server

Additional Info

Example of Systems and Connections in DMZ Scenario

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:

METHOD regenerate_kpro_url.

* Method Parameter
* CV_URL  Changing	Type c length 4096

  CONSTANTS: cv_expl_location TYPE  c VALUE 'E'.

  DATA: lv_rfc_call TYPE boole_d,
        lv_dmz_host TYPE syhost,
        lv_location TYPE sdok_loc,
        lv_http_url TYPE c length 4096.
        lv_https_url TYPE c length 4096.
* check if called by SPI RFC.
  CALL METHOD /plmb/cl_spi_factory=>check_called_by_rfc
    IMPORTING
      ev_called_by_rfc = lv_rfc_call.

  IF lv_rfc_call IS NOT INITIAL.
*   determine Location in KPRO Distribution Customizing .
    CALL METHOD /plmb/cl_spi_factory=>get_dmz_host_name
      IMPORTING
        ev_dmz_host_name = lv_dmz_host.

    CALL FUNCTION 'SCMS_LOCATION_GET'
      EXPORTING
        host      = lv_dmz_host
      IMPORTING
        location  = lv_location
      EXCEPTIONS
        not_found = 1
        OTHERS    = 2.
  ENDIF.

  IF lv_location IS INITIAL.
*    nothing to change
    RETURN.
  ENDIF.

  CALL FUNCTION 'SCMS_URL_REGENERATE'
    EXPORTING
      absolute_uri    = cv_url
      use_location    = cv_expl_location
      location        = lv_location
    IMPORTING
      http_uri        = lv_http_url
      https_uri       = lv_https_url
    EXCEPTIONS
      error_parameter = 1
      OTHERS          = 2.
  IF sy-subrc <> 0.
    MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
            WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
    RETURN.
  ENDIF.

  IF lv_https_url IS NOT INITIAL.
    cv_url = lv_https_url.  " 1. choice https
  ELSE.
    cv_url = lv_http_url.   " 2. choice http
  ENDIF.

ENDMETHOD.
  • No labels