Secure and Fail over Configuration for JDBC Adapter SAP PO
In this blog I would like to share the available JDBC option to encrypt the message transfer and failover configuration to have uninterrupted connection during the maintenance of one DB server.
- Encryption Option in JDBC:
Data Security is the inevitable requirement in this growing technical world. As a mostly used middleware for transferring data between different systems and companies, SAP Process Orchestration should majorly investigate the available security option for its standard adapters to ensure all the customer data is safe and secured while transferring.
The encryption of the data sent to the Oracle database is taken care by the JDBC driver and not by the PI as every database provides their own data encryption feature. So, the driver parameter should be provided by the Admin of the database which is involved in the integration.
In any network connection, it is possible for both the client and server to support more than one encryption algorithm and more than one integrity algorithm.
To negotiate whether to turn on encryption or integrity, you can specify four possible values for the Oracle Advanced Security encryption and integrity configuration parameters. The four values are listed in the order of increasing security.
If the DB side is set to REQUESTED, ACCEPTED, or REJECTED, the connection continues without error even if you use this in JDBC Channel and without the security service enabled.
This parameter need not to be enabled explicitly, if you do not wish to have an encrypted communication with the DB.
This Parameter value will enable the encryption if it is set as requested / required on the DB side and the Algorithm which we are using should match the available algorithm on the DB side.
These kinds of parameters are mostly used on the DB side, Since the server might have connection to multiple clients some of which may not enable encryption option at their configuration.
In this way the connection will be secured if client wish to have and communication will happen without any errors even without encryption.
This parameter can be used if the server side permits to have encrypted connection. As usual it works if the algorithm sent and maintained are matching between the systems.
This is the needed parameter in case you want to allow only encrypted communication between the SAP PI/PO and Database server. This is the recommended one on client side to not to compromise security.
In this scenario, JDBC Channel with REQUIRED specifies that the security service must be enabled. The connection fails if the other side specifies REJECTED or if there is no compatible algorithm on the other side.
By Default, DB doesn’t enable encryption parameters and can be set based on the request during the connection. Below is the Encryption and Data negotiation chart which clarifies this.
|SAP PI/PO||Database Server||Encryption and Data Negotiation|
The below is the sample which DB team could share with us and it should be prefixed with “driver:” when we use it in JDBC Channel.
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA1)
SQLNET.ENCRYPTION_TYPES_SERVER = (AES256)
SQLNET.CRYPTO_CHECKSUM_SERVER = ACCEPTED
SQLNET.ENCRYPTION_SERVER = ACCEPTED
To conclude the encryption part, REQUIRED is the recommended parameter value on our JDBC Channel considering the DB doesn’t reject encrypted communication.
2.Failover String in JDBC:
Sometimes SAP PO interfaces using JDBC adapter may transfer business critical data which cannot be delayed for any reasons.
To support high availability of business, the company may have two Databases in parallel (2 separate Hosts, which can be addressed via separate IP or hostnames, one is active, one is passive). In such cases the SAP PI/PO should have the ability to automatically switch from one to the other without manual interaction when there is a downtime with the active database.
To ensure this fail-over connection, below mentioned JDBC connection string can be used for Oracle DB connection from SAP PI/PO.
jdbc:oracle:thin:@(DESCRIPTION =(CONNECT_TIMEOUT=3)(TRANSPORT_CONNECT_TIMEOUT=3)(RETRY_COUNT=3)(ADDRESS_LIST =(FAILOVER = ON)(LOAD_BALANCE = ON)(ADDRESS =(PROTOCOL = TCP)(HOST = <Active database>)(PORT = <port>))(ADDRESS = (PROTOCOL = TCP)(HOST = <Passive database>)(PORT = <port>)))(CONNECT_DATA =(SERVER = DEDICATED)(SERVICE_NAME =<Service name>)))
Active database: FQDN of the primary server to be connected from the PI system.
Passive database: FQDN of the secondary server to be connected from the PI system.
Port: Listening port of the DB server.
Service name: Dedicated service schema used for this connection.