Administrator

Creating a Destination

Create destinations for the services to point to the data source from which the data is fetched.

Procedure

  1. In the Management Cockpit, select Start of the navigation path OData Services Next navigation step Destinations End of the navigation path.
  2. Click New Destination.
  3. Enter the information that is appropriate to the type of data source you want to connect to:
    Table 27: Database (JDBC)
    Field Description
    Destination Name Enter the name for the destination.
    Destination Type Select DATABASE.
    URL Enter the destination URL of the JDBC data source you are connecting to. For example, jdbc:hsqldb:mem:com.sap.sample.
    Database Driver Enter the JDBC driver that enables the processor to connect to the database. For example, org.hsqldb.jdbcDriver.
    Authentication Type Select,
    • No Authentication: if no authentication is required to access the JDBC data source.
    • Basic Authentication: if a user name and password is required to access the JDBC data source.
    User Name If you selected Basic Authentication type, enter the user name to access the JDBC data source.
    Password Enter the password to access the JDBC data source.
    Table 28: HTTP
    Field Description
    Destination Name Enter a name for the destination.
    Destination Type Select HTTP.
    URL Enter the destination URL of the data source you are connecting to.
    Authentication Type Select,
    • No Authentication: if no authentication is required to access the data source.
    • SSO Mechanism: choose an SSO mechanism depending on the authentication providers that are configured in the security profile associated with the application.
    Certificate Alias If you selected <Technical User (X.509)> or <X.509>SSO mechanism, enter the certificate alias name of the private key (of the user) and technical user certificate that is used to access the back-end system; otherwise, leave the entry blank. The alias is located in smp_keystore.
    SSO Mechanism You can add one or more SSO mechanisms, and prioritize them. The runtime calls the first SSO mechanism for which corresponding user credentials are available. Only one SSO mechanism is used per connection attempt. If the connection fails, the server invalidates the client session and requires reauthentication.
    1. If you selected SSO Mechanism, click Add in the SSO Mechanisms section and choose from the following types and enter property values if required:
      • Basic: use the basic authentication mechanism to access the data source (user name and password provided by the user is forwarded to the back-end in the HTTP Basic Authentication header).
      • SSO2: use the SAP SSO2 mechanism to access the data source. Authenticates the user to the back end using a MYSAPSSO2 token. You can use this mechanism only if an HTTP/HTTPS provider is configured in the security profile, and it authenticates the end user to SAP Mobile Platform Server against a Web server that returns a MYSAPSSO2 token.
      • X.509: select this option when the client has authenticated using HTTPS and X.509 certificates for mutual authentication. If this mechanism is used with Principal Propagation authentication provider, SAP Mobile Platform generates short-living X.509 certificates and sign them with the configured key. This mechanism connects to the back-end using the configured technical user X.509 certificate. The end-user certificate is passed in the SSL_CLIENT_CERT HTTP header. Configure the back end to allow the technical user to impersonate the end user and execute the request in the context of the end user. The end-user certificate may be generated by the Principal Propagation provider that is configured in the security profile, or it may be supplied by the end user when he or she authenticates to the server over a mutually authenticated HTTPS connection. You can use this mechanism with either the X.509 authentication provider or the Principal Propagation provider that is configured in the security profile.
      • Kerberos: enter the Kerberos realm and the service name. This mechanism connects to the back-end by setting the Kerberos token value in the Authorization: Negotiate <Kerberos token ticket value> header. Configure the back-end to authenticate users with Kerberos. You can use this mechanism only if the Kerberos provider is configured in the security profile. The server obtains a Kerberos access token for the specified realm and service name. The realm contains the back-end resources to which you want to provide SSO access.
      • Technical User (Basic): enter the user name and password for the technical user. Connects to the back-end using these credentials. You can use this SSO mechanism with any authentication-provider configuration in the security profile.
      • Technical User (X.509): connects to the back-end using the configured technical-user X.509 certificate. You can use this mechanism with any authentication-provider configuration in the security profile.
      • Custom Cookies/Headers: sends configured headers/cookies with values that are derived from a regular expression. This is a generic mechanism to pass SSO details that are not covered by other explicit mechanisms. Click Add Custom Property under Custom Properties and enter:
        • Name – name of the header or cookie.
        • Pattern – header or cookie value.
        • Type – header or cookie.
    2. Click Save. The SSO mechanism must appear in the New Destination screen.
    To set the order in which multiple SSO mechanisms are used, click the up or down arrow adjacent to the name.
     
    Table 29: JPA
    Field Description
    Destination Name Enter a name for the destination.
    Destination Type Select JPA.
    Persistence Unit Enter the name of the JPA persistence unit as it is defined in the persistence.xml file (created in the META-INF directory).
  4. Save the settings.