After enabling OCB features, you should check if folders and files are correctly available in SMP3. In theory, the enablement worked, when OCB files are available in the features, plugins and webapp folder of SMP3.
ls /SAP/MobilePlatform3/Server/features/ | grep "com.sap.banking.omnichannel*"
While installing OCB, SMP3 had to be stopped. During the installation, the database was prepared and files that represent the OCB application were copied to SMP3. Those bundles are now available in SMP3 (OSGI bundles), but are not activated. To be able to use OCB, the features must be activated by SMP3 administration in the Admin web interface. First, start SMP3.
Add OCB p2 repository
Log on to the SMP3 admin interface and navigate to settings -> repositories
To be able to install SAP Omnichannel retail banking on SMP3 SP8, some adjustments must be done on the SMP3 server configuration.
Avoid memory leak
Add a new parameter in the props.ini file of SMP3 server.
Parameter to add: -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true
Looking at the installation guide from SAP, this configuration is somewhat against SAP’s own security recommendations, but is needed as OCB uses struts, and for those the validation must be done via DTD and not by XSD. Edit the file fixed-sys.properties located at /SAP/MobilePlatform3/Server/configuration/com.sap.mobile.server.launcher.
Comment out the last two properties.
Weak Diffie-Hellman ciphers
New browser don’t like anymore the SMP3 SP8 standard TLS ciphers, therefore these must be changed to be more aligned with latest security expectations.
For each TLS connector, substitute the ciphers by TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA.
Form the above connection parameters you can see that SMP3 is going to use the user gomobile with the password secret to connect itself to Oracle XE. This means that the user with the password and a schema must be created in the DB. SMP3 comes with a SQL script for Oracle that does exactly that. The script is located at /db_tools/db/oracle/smp3/sql. The file is 001_SMP3_drop_and_create_user.DDL The file contains the SQL statements to create the user with the right permissions:
CREATE ROLE SY365_OBJOWNER;
GRANT CREATE SEQUENCE TO SY365_OBJOWNER;
GRANT CREATE SESSION TO SY365_OBJOWNER;
GRANT CREATE SYNONYM to SY365_OBJOWNER;
GRANT CREATE TABLE TO SY365_OBJOWNER;
GRANT CREATE VIEW TO SY365_OBJOWNER;
GRANT CREATE PROCEDURE TO SY365_OBJOWNER;
GRANT CREATE SEQUENCE TO SY365_OBJOWNER;
GRANT CREATE TRIGGER TO SY365_OBJOWNER;
GRANT CREATE INDEXTYPE TO SY365_OBJOWNER;
DROP USER GOMOBILE CASCADE;
CREATE USER GOMOBILE
IDENTIFIED BY secret
DEFAULT TABLESPACE USERS
TEMPORARY TABLESPACE TEMP
-- 2 Roles for GOMOBILE
GRANT SY365_OBJOWNER TO GOMOBILE;
GRANT CREATE SESSION TO GOMOBILE;
GRANT CONNECT TO GOMOBILE;
ALTER USER GOMOBILE DEFAULT ROLE ALL;
-- 1 Tablespace Quota for GOMOBILE
ALTER USER GOMOBILE QUOTA UNLIMITED ON USERS;
You’ll have to add the command EXIT; at the end of the file
SQL*Plus: Release 188.8.131.52.0 Production on Wed Aug 24 21:37:08 2016
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Oracle Database 11g Express Edition Release 184.108.40.206.0 - 64bit Production
DROP USER GOMOBILE CASCADE
ERROR at line 1:
ORA-01918: user 'GOMOBILE' does not exist
The error regarding DROP user is normal, as the user gomobile hasn’t been created before, so there is no user to drop.
SMP3 runs on Tomcat, and therefore inherits its basic configuration from Tomcat. One of these is the session timeout parameter. By default, timeout is set to 20 minutes. Depending on your requirements this can be too short or too long. Changing the value is easy as you only have to change one parameter in one file and restart SMP3 to make the change take effect. The procedure is outlined at SAP Help.
The file to be changed is the Tomcat configuration file that can be found at: <SMP_HOME>\Server\config_master\org.eclipse.gemini.web.tomcat\web.xml.
The parameter to change is: session-timeout.
To increase the timeout to 1 hour, change it to 60.
SSL is out, TLS is the new kid in town (although already pretty old) and to keep security high on your SMP3 server, a question remains: how to enable TLS on SMP3? Easy: it is already configured!
By default, SMP3 comes with TLS enabled. The trick is to configure it how you want it to be. For once, there are the ciphers (not part of this blog) and the protocol. The protocol defines if a browser can use TLS v1, v1.1 or v1.2. The configuration is done on the server side, in the default-server.xml file located at:
Port: defines the port Tomcat will listen on. Here it is 8081
sslEnabledProtocols: “The comma separated list of SSL protocols to support for HTTPS connections. If specified, only the protocols that are listed and supported by the SSL implementation will be enabled.” 
sslProtocol: “The SSL protocol(s) to use (a single value may enable multiple protocols – see the JVM documentation for details). If not specified, the default is TLS” 
Connecting to the port results in a TLSv1 connection:
The parameters that define which protocol can be used are sslEnabledProtocols and sslProtocol. Now, which one does what? I found  and  explaining this:
setProtocol=”TLS” will enable SSLv3 and TLSv1
setProtocol=”TLSv1.2″ will enable SSLv3, TLSv1, TLSv1.1 and TLS v1.2
setProtocol=”TLSv1.1″ will enable SSLv3, TLSv1, and TLSv1.1
setProtocol=”TLSv1″ will enable SSLv3 and TLSv1
In the above example, sslProtocol = TLS, therefore TLSv1 and SSLv3 is available. To limit the connection to TLSv1, sslEnabledProtocol must be set to TLSv1. To have a connection that allows for TLSv1, TLSv1.1 and TLSv1.2 (and let the browser decide which one to use), set sslEnabledProtocols to TLSv1,TLSv1.1,TLSv1.2.
As of SMP3 SP07 you can use SAP Web Dispatcher as a reverse proxy for SMP3. Depending on your landscape, this simplifies A LOT your architecture. And you can reuse your WD knowledge and gain support from SAP. Installing the WD is done as usual, with one caveat: you have to inform the commonlib which TLS to use:
ssl/ciphersuites = 896:HIGH
With this, WD can connect to SMP3 using TLS. While this may look strange, it actually is necessary as SMP3 uses some high TLS security.
To understand better what these two parameters do, take a look at the Commonlib + WD SAP Note: 510007
A complete sample profile from a WD running on Windows
SAPSYSTEMNAME = WDP
SAPSYSTEM = 00
DIR_INSTANCE = C:\<dir>\SAPWDSMP3
DIR_EXECUTABLE = $(DIR_INSTANCE)
DIR_PROFILE = $(DIR_INSTANCE)
DIR_HOME = $(DIR_INSTANCE)
Autostart = 1
Restart_Program_00 = local $(DIR_EXECUTABLE)/sapwebdisp$(FT_EXE) pf=$(DIR_PROFILE)/sapwebdisp.pfl
SMP 3 is a Java application running inside Virgo. To not have to worry about Java versions and installation, the installer even installs SAP JVM together with the server. So you have a SMP 3 installation and a Java installation at hand. This means that you get automatically Java security features … and some legacy problems that come from the dark ages of Internet. One is that you have to enable Strong encryption for SMP3’s Java. This is needed at least when you are going to use SAML2 with ADFS as authentication provider. SAML 2 allows the IdP to encrypt the SAML response to make sure only the SP can decrypt it. The encryption algorithm used there is using Strong encryption methods. These are not available by default to Java. They need to be activated manually.
The procedure for how to do this can be found at SAP Help. To enable Strong encryption, a policy file must be downloaded from Oracle and placed into a Java folder.