PoC using SOA Suite Cloud Service (188.8.131.52): lessons learnedPublished on: Author: Eduardo Barra Cordeiro Category: Oracle
Qualogy executed a successful proof of concept (PoC) for a client in the Netherlands to confirm that SOA Suite Cloud Service (SOACS) is the expected solution to integrate Oracle eBusiness Suite 12c with third parties. In this post, Qualogy's Eduardo Barra Cordeiro summarizes the highlights from this short project, including lessons learned and the problems and solutions encountered during the project.
First, we defined the goals for the PoC, including what is and what is not expected. We generated a document for reference so we can confirm, at the end, if we achieved the goals or not.
Some other activities executed during the PoC:
- Client requested a SOACS instance in the Oracle Cloud (if you want to have an estimate of how much it will cost to use Oracle public cloud, check this link: https://cloud.oracle.com/en_US/cost-estimator);
- Qualogy to setup the connectivity on cloud side with client network;
- Qualogy to define, together with the client, the integration requirements, including WSDL contract and data types;
- Qualogy to develop the BPEL code and implement the required integration;
- Qualogy to execute a performance test to check if the expected load will be supported by the infrastructure
This is the business flow that has been implemented:
This is the Cloud instance overview:
During the PoC definition, the client requested we deliver some answers to their questions at the end. Follow some of them.
Pros and cons about SOACS
There is an article from Marcello Morettoni that highlights a few pros about SOACS usage:
- for complex and hybrid integrations involving SaaS, PaaS, cloud, on-premise or hybrid cloud, where protocols such as WS-*, REST, WSDL, XML / XPath / XQuery / XSLT, SCA, UDDI are required, SOACS is a strong and unified platform of resources for a lot of your business needs. Oracle SOACS helps businesses to reduce costs by allowing maximum reusability of existing IT investments and assets, regardless of the environment they run in;
- product maturity level: Oracle considers it mature and functionally complete;
- the development and the workload can be used in the same way, for both SOACS and SOA Suite on-premise versions;
- it features the Oracle Service Bus, which is the market-leading and fastest growing enterprise service bus (ESB). Oracle Service Bus mediates and provides location-independent access to services across a service network that can span various applications.
Regarding the cons:
- in the PoC scenario, the client did not have SOA developers in house. For BPEL development, knowledge in XML, XSD, XSLT, and standards other than BPEL coding is necessary. During troubleshooting, it can be difficult to find a solution for problems in transformations and assignments activities;
- it is also required to have knowledge in WebLogic administration, because it is the application server;
- the Oracle documentation is not organized in a way that starting developers in BPEL can easily understand;
- there could be unknown product bugs, meaning a patch would be necessary.
Setup EBS with SOA Gateway
Implementing an integration with EBS is quite simple and can be done in different ways. SOACS provides an adapter for this, but it is also possible to use SOAP/REST calls. For both it is necessary that you enable the SOA Gateway in the EBS layer. Further information can be found here: https://docs.oracle.com/cd/E18727_01/doc.121/e12064/T291171T509748.htm
BPEL exposed as SOAP and REST
One of the requirements was to expose the BPEL composite in both SOAP and REST.
Security and GDPR
General Data Protection Regulation (GDPR) is a regulation in EU law on data protection and privacy for all individuals within the European Union (EU) and the European Economic Area (EEA). It also addresses the export of personal data outside the EU and EEA areas. The GDPR aims primarily to give control to individuals over their personal data and to simplify the regulatory environment for international business by unifying the regulation within the EU (further information can be find here).
Two different aspects are considered to be part of the GDPR compliancy:
- product compliancy: in the link below Oracle gives a clear idea about the Oracle GDPR extension using PaaS: https://www.oracle.com/nl/applications/gdpr/. Short answer: yes, the product is GDPR compliant.
- project compliancy: in project architecture definition and setup, you need to have a specific setup to be compliant with GDPR:
- protect user data. Use secure webservices and encryption for this;
- don’t save any personal data that will be transit in the integration. This information must be defined during the business analyses document, and implemented in the development phase. In the implementation an easy way to find and delete such data must be considered, in case the user requests it;
- establish a secure connection between SOA Cloud servers and Fluke network. Only the client should be able to connect into exposed SOA Cloud services and vice-versa;
- consider avoiding public internet connections, and instead use private providers for connectivity solutions.
Roles and profiles in an integration project using SOA CS project
For the client, we defined a few profiles of people that should be involved in an integration project.
- Business/integration analyst: this person (or team) will be responsible for the design of all the integrations from the business perspective. An example of how important the analyses are in such a project occurred during the POC. Instead of using two EBS APIs to connect to the EBS client, we defined a single one, replying to the BPEL client in full detail about the order in a single request.
Also, it is important to define the canonical models before developing the integrations. When the documentation is ready, BPEL development can start.
- SOA Integration Architect: this person (or team) will be responsible for defining what resources will be used during the integration, such as BPEL, OSB, Mediator, and how to connect in each third part application (adapters definition).
This person will also provide information about how to set up the connectivity between SOA Cloud environment and client infrastructure, and define the security policies that should be used in the implementation.
- Oracle Cloud Consultant: this person (or team) will be responsible for the setup of Oracle Cloud, including network settings, grants and rules definition, virtual machine setup, CPU and memory, database, SOA instances and everything related. This is required at the beginning of the project and on demand, if need be.
- WebLogic Consultant: this person (or team) will be responsible for the setup on the application server side, including grants, certificates configuration and issues. This is required at the beginning of the project and on demand, if need be.
- BPEL developer: this person (or team) will be responsible for the documentation they receive from the analyst and the technical specification they receive from the architect. They will create the BPEL code and unit tests, and support integration tests with third parties. Their assistance will be required until the deployment is in production, and for support for eventual bug codes.
- OSB developer: in case the project architecture includes an OSB layer to expose the BPEL services in a service bus layer, a developer will be required to code the projects.
As part of the results for the PoC we used a simple SOAPUI testcase to run 1000 calls to the exposed BPEL service. The results demonstrate the performance for the SOACS environment.
- SOAPUI did 1000 calls to the exposed SOAP BPEL process
- We set up 5 threads simultaneously
- Total duration to execute 1000 calls: 6 minutes and 24 seconds
- Average transactions per second: 2,6
- Average execution time: 1,2 seconds
- Faster execution time: 0,8 second
- More time-consuming execution time: 2,3 seconds
- Count of errors/faults: zero
- Success calls (without error): 100%
- Errors on the SOA Cloud server: no errors
- SOA Cloud server processor load during test: under 10%
The result was at least 100 times faster than the client expected. This proves that the infrastructure is good enough to support their load.
Problems and solutions
During the execution, we found some challenges that could be useful for future PoCs:
- To set up a certificate on the WebLogic, use the instructions from this blog: https://www.qualogy.com/techblog/oracle/configuring-saml-in-oracle-service-bus-%28osb%29-12c-and-tracing-your-messages
- By default, the WebLogic server in the SOACS starts with an extra parameter. This will create problems with setting up the client certificate if you need to use https calls.
Execute the activities below to remove this entry, and to be able to configure the client certificate:
- Remove property value (see below) from setDomainEnv[.cmd|.sh]
- For more details: https://sswaro.wordpress.com/pkix-path-building-failed-in-soa/
- This error will show even after the certificate had been installed correctly if this property is there:
- oracle.fabric.common.FabricInvocationException: javax.xml.ws.WebServiceException: Could not determine wsdl ports. WSDLException: faultCode=PARSER_ERROR: Failed to read wsdl file at: "https://client.dev/webservices/SOAProvider/plsql/client_soap_webserv/?wsdl", caused by: javax.net.ssl.SSLHandshakeException.: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
3. We hit a product bug during the transformation using CDATA content. When we receive the character & inside an XML element, the SOA engine replaces it to & . So when we parse the data in the functions parseEscapedXML, it fails. The solution is to use parseXML instead.
It is a known bug, described in the Oracle document. ParseEscapedXML is unable to parse the special character & (ampersand) (Doc ID 2038137.1).
At the end of the the PoC, we were able to declare it a success based on the premises defined in the beginning of the project. A few points we can highlight:
- Oracle Cloud is a stable and easy to work with environment.
- To create a SOA CS instance, we have a quick starts option that will trigger a script with required setup (machine, storage, database, WebLogic, SOA Suite and network configuration).
- We can use the Oracle Cloud interface to manage the instances, including the access to the consoles, define the access rules, SSH access and also network definition. There is a similar interface to manage the cloud machine, storage, memory and everything related to the instance.
- Other than these instances, the WebLogic/SOA Suite maintenance is the client’s responsibility. Only the cloud infrastructure is owned and managed by Oracle.
- The client was satisfied with the results. All requirements discussed during the preparation have been delivered and the performance was much better than the expected, even considering the low volume.
- They decided to use SOA CS as the integration solution.