We had our first SOA Testing webcast “Hitchhikers Guide to end-to-end SOA B2B Testing” yesterday where we dived into the world of SOA and Testing to make sure that your organization doesn’t let a false sense of safety compromise your SOA integration. If you missed it, you can download the presentation here.
1. What tools do you use for headless EJB testing?
There are several well documented options for headless Java testing that range from automating your test suites written in JUnit or TestNG using Apache Ant or Maven to adopting a continuous integration development practice. Please refer to the following link for Oracle’s 12c documentation on the subject:
EJB interface technologies include SOAP, REST and JMS. We use SoapUI as with a single tool we can test all 3 different EJB interfaces. SoapUI provides a way to run and retrieve reports of of SoapUI test suites by utilizing Apache Ant or Maven.
2. Can this tool be used to test ADF applications?
No, the tool presented in the demo video is Oracle’s official SOA Composite Test Framework and it is designed to test Oracle SOA Suite Composites.
There are several options to test ADF applications following are links on how to create JUnit tests for ADF and how to use Selenium to test the Web Pages:
3. Can you expand on “use real data in your Test Case Emulates”?
As a general rule of thumb in testing you should test with data as similar to the data the application will process in a live Production environment. When “use real data” was specified in the webcast the intention was to remind people of this rule of thumb. When an emulate is created you have the option of manually entering data or to load data from a file. Most of the time during development you will select enter manually and will hit the “Generate Sample” button. This button will generate “dummy” data, not “real data”, for example any elements that are of type String will have data generated as “string1”, “string2”,… “string#”. So you should make sure you replace those generated values with “real data”. Data that has empty spaces, special characters and/or any kind of possible values the system will have to process in production for the given element. The easiest way to obtain this data is to run your composite in at least a TEST or UAT system and retrieve XML Payloads from Oracle Enterprise Manager and use them in you emulates.
4. Do you use SOAPUI for testing EJBs?
Please refer to Question #1. In short yes, we use SoapUI to trigger call to the different EJB interfaces, that can be SOAP, REST and/or JMS based. Additionally, would like to mention that SoapUI can also be used to perform EJB performance testing. Once a SoapUI Test Plan has been created to perform functional testing, the requests can be reuse to create performance tests to make sure our EJBs meet any required SLAs.
5. How do you implement B2B for multi countries, like US or CA? Does B2B provide any multi Org capabilities?
One way to accommodate multi countries and multi orgs in B2B is to handle it at the SOA Composite layer and EBS E-Commerce Gateway.
For the consideration of multiple organizations, you can associate Trading Partners with operating units linked to your responsibility through the Trading Partner Group setups. Once a Trading Partner Group is linked to an operating unit, all Trading Partners within the group are all automatically associated with the selected operating unit; the associated Trading Partner addresses are also linked to the selected operating unit as well. Additionally, the Trading Partner Type, such as a customer, supplier, or bank, will also be restricted to the operating unit.
Trading Partner data must be set up both in your EDI translator software and in the Oracle e-Commerce Gateway. The set up parameters are quite different to satisfy their particular needs.
In the Oracle e-Commerce Gateway, Trading Partner data is used to:
- Link to a specified operating unit
- Link a particular address location in Oracle E-Business Suite to the Trading Partner definition in the Oracle e-Commerce Gateway
- Provide a means of telling the EDI Translator which Trading Partner data maps and mailbox are to be used (outbound transactions)
- Enable specific transactions for Trading Partners
- Determine if the EDI status of a Trading Partner is Test or Production
6. We have sometimes stuck threads. Is there any way to kill the struck threads without bring down the SOA server.
Yes, stuck threads can be killed without bringing down the SOA Server. The key is to identify which threads are stuck. Once they have been identified composite instances can be aborted to kill the stuck threads without bringing down the server. For the cases that Oracle Enterprise Manager cannot be used to identify the stuck threads is important to have useful logging messages. Finally, once raise conditions or areas of a composite have been identified where threads can be stuck along with adding logging message timers can be used to stop execution.
7. What tools are recommended for SOA testing? What do we need to consider while selecting the tool?
In addition to the Oracle SOA Suite Composite Test Framework presented in the webcast, we recommend to use the component test for the BPEL process service component. Similarly, Oracle provides a testing tool they call Simulations for BPM processes. ADF UI pages of Human Task activities can be testing using Selenium. In terms of Java code JUnit and/or TestNG are the way to go to create unit test. Finally, I would recommend a comprehensive automated way to run all your tests and for that I would refer you to the following Oracle FMW 12c link on the subject:
8. We have been facing performance challenges after SOA implementation. What would have been the best possible way to prevent such issues in first place?
- Do a comprehensive analysis and design phase to determine all your uses cases that you currently run as well as future projections.
- estimate the growth of your transaction volumes best case, medium and worst case scenarios.
- Do a proper sizing exercise based on Oracle recommendations for SOA Suite.
- Build your system according to an Oracle SOA Enterprise Deployment and uses a SOA Framework which enforces best practices that is highly extensible.
- Adopt proper testing best practices.
- Consider a hosted/managed service approach to SOA.
- Consider implementing SOA on Oracle Exalogic/Exadata Engineered Systems.
9. What are BPEL processes and how do you perform BPEL testing?
BPEL stands for Business Process Execution Language. It is the main workflow engine in Oracle SOA Suite. It is a XML based language built on Web Service Standards and is an OASIS standard. BPEL processes invoke remote services which can be Web Services, but can also be Database, AQ, FTP among many others and provide data manipulation and control flow. Also, they provide process orchestration of long running transactions along with fault handling an compensation activities.
There are several ways to test BPEL process and the top four are mentioned next. The first is Oracle’s component test for BPEL process service components which has been available since Oracle SOA Suite 184.108.40.206 and 12c documentation can be found at:
A second option is to create test cases using the Oracle’s SOA Suite Composite Test Framework and leverage the Asserts and Emulates going into and out of the BPEL process to exercise execution paths based on business requirements.
A third option is to go to the composite in Oracle Enterprise Manager’s Test tab, select operation and provide security policy and credentials as needed and run the test to initiate the composite instance.
Finally, SoapUI can be used to trigger a composite instance containing a BPEL process.
10. How do you make sure that test cases and test suites address business requirements in Oracle SOA?
First thing, first, business requirements need to be documented. There needs to be a basic agreement and understanding of use cases, what are the composite input parameters and what is the expected output for each use case. Flow diagrams are a great tool to understand how data is enriched and/or transformed and the different states data can be in.
The key to make sure that test cases and test suites address business requirements in Oracle SOA is to create test suites and test cases top to bottom.
By top to bottom we refer to developing the test cases based on business requirement use cases. Based on the input parameters and the expected output for each of the business requirement use cases.
11. Do you run existing test suites before delivering code to your Oracle SOA stable code line for any packages/services modified to avoid code regressions?
Correct, we do and we recommend to execute test suites relevant to any code being delivered to avoid introducing regressions. Additionally, we follow and recommend following version control best practices, like performing development from a branch and not trunk and only delivering code to trunk after all tests pass.
12. What are the benefits of SOA test automation?
Highlights of SOA test automation benefits are:
- Time and effort savings, manual testing can be avoided or reduced, which can be a lengthy and error prone process, not only time and effort is saved during testing phase, but also during development as now developers can quickly run existing test cases instead of manually testing, all this results in shortened project delivery timelines
- Confidence, test can be run on a schedule and if combined with a build system, they provide you the ability to know multiple times through the day the status of your code base, also developers confidence is increased by providing them additional feedback
- Automated reports, not only do test are executed, but reports are generated with the results of the tests, providing instant feedback
- Automated tests can be run before and after performing new development or code changes to avoid introducing regressions
- Test automation of UI component of Human Task or standalone ADF applications can also provide time and effort savings, especially when supporting multiple browsers and multiple languages