PoC using SOA Suite Cloud Service (184.108.40.206): lessons learnedPublished on: Author: Eduardo Barra Cordeiro Category: Oracle
Qualogy executed a succesful proof of concept (PoC) at 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. A document has been generated to be used as reference and confirm, at the end, if we achieved the goals or not.
Some other activities executed during the PoC:
- Client to request a SOACS instance in the Oracle Cloud (if you want to have an estimative about how much will be your cost using Oracle public cloud, use 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 request us to deliver, at the end, some answers to their questions. Follow some of them.
Pros and cons about SOACS
There is an article from Marcello Morettoni that brings some pros about SOACS usage:
- for complex and hybrid integrations involving SaaS, PaaS, cloud, on-premise or hybrid cloud, where protocols as WS-*, REST, WSDL, XML / XPath / XQuery / XSLT, SCA, UDDI are required, SOACS is a strong and unified platform of resources for many of business needs. Oracle SOACS helps businesses to reduce costs by allowing maximum re-use 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 on the same way for both SOACS and for SOA Suite on-premise versions;
- it brings 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 didn’t have SOA developers in house. For BPEL development necessary knowledge will be needed in XML, XSD, XSLT and other standards other than BPEL coding. During troubleshooting it can be a problem to easy find a solution for problems in transformations and assignments activities;
- it will also be required knowledge in WebLogic administration, as it is the application server;
- the Oracle documentation is not organized in a way to easy support developers that just started to develop in BPEL;
- we can hit in known product bugs and a patch could be necessary.
Setup EBS with SOA Gateway
To implement an integration with EBS is quite simples and can be done in different ways. SOACS provides an adapter for this product but it is also possible to use SOAP/REST calls. For both it is necessary enable in EBS layer the SOA Gateway. Further information can be found here in this link: https://docs.oracle.com/cd/E18727_01/doc.121/e12064/T291171T509748.htm
BPEL exposed as SOAP and REST
As part of the requirements, the client asked 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).
There are two different aspects to be considered as part of the GDPR compliancy:
- product compliancy: in the below link Oracle gives a clear idea about Oracle GDPR extension using PaaS: https://www.oracle.com/nl/applications/gdpr/. Short answer: yes, the product is GDPR compliancy.
- project compliancy: in project architecture definition and setup it is need to do some specific setup to be in compliancy with GDPR:
- protect user data, using for that secure webservices and encryption;
- avoid to save any personal data that will be transit in the integration. Such information must be defined during the business analyses document and implemented in development phase. The implementation must consider a way to easy find and delete such data in case the user request for it;
- stabilish 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 to avoid public internet and use private providers to connectivity solutions.
Roles and profiles in an integration project using SOA CS project
We defined for the client some profiles of person 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. One example of how important the analyses is in such project occurred during the POC. Instead of use two EBS API’s to connect the EBS client, we defined a single one, replying to the BPEL client full details about the order in a single request. Also, it is important to define the canonical models before develop the integrations. With the documentation ready BPEL development can start.
- SOA Integration Architect: this person (or team) will be responsible to define what will be the resources used during the integration, such as BPEL, OSB, Mediator, and how to connect in each third part application (adapters definition). Other than that, the person will provide information about how to setup the connectivity between SOA Cloud environment and client infrastructure and define the security policies to 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 all related. It will be required in in the beginning of the project and on demand, if need.
- WebLogic Consultant: this person (or team) will be responsible for the setup on the application server side, including grants, certificates configuration and issues. It will be required in in the beginning of the project and on demand, if need.
- BPEL developer: this person (or team) will be responsible to receive the documentation from the analyst, the technical specification from the architect and create the BPEL code. Also, they will create unit tests and support integration tests with third parties. Their engagement will be required until the deployment in production and support for eventual bug codes.
- OSB developer: in case the project archicteture include OSB layer to expose the BPEL services in a service bus layer, it will be required a developer to code the projects.
As part of the results for the PoC we used a simple SOAPUI testcase in to run 1000 calls to the exposed BPEL service. Tthe results demonstrate the performance for the SOACS environment.
- SOAPUI did 1000 calls to the exposed SOAP BPEL process
- We setup 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%
This result was at least 100 times faster than the expected by the client. It proves that the infrastructure is good enough to support their load.
Problems and solutions
During the execution we find some challenges that can be used in future PoCs:
- To setup a certificate on the WebLogic, use the instructions from this old previous: 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 that will create problems to setup the client certificate in case you need to use https calls.
Execute the bellow activities to remove this entry and be able to configure the client certificate:
- Remove below property value from setDomainEnv[.cmd|.sh]
- More details here: https://sswaro.wordpress.com/pkix-path-building-failed-in-soa/
- This error has been show even after the certificate 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 is replacing it to & . 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 are able to declare it a success based on the premisses defined in the beginning of the project. Some points that we can highlight:
- Oracle Cloud is an environment stable and easy to work with.
- 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 all related with the instance.
- Other than the instances, the WebLogic/SOA Suite maintenance is client responsibility. 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.