Doorgaan naar hoofdcontent

WSO2 ESB - Design for testability

Introduction


Testability is one of the underestimated qualities of software. This is also the case for WSO2 ESB projects. However it is important to design the integrations for testability and this starts with the way you setup the proxies. This blog gives some guidelines which you can use to design for testability.

Sequences

Sequences are a way in WSO2 to group Mediators. A proxy has by default an in-Sequence, out-sequence and optionally an error-sequence. These sequences can be split up in sub-sequences and this is a good way for reuse, but also a way to split up the design. A proxy usually contains the following functional parts:
  • Validation
  • Transformation
  • Sending to an endpoint
 









These parts can be put in separate sequences. This has the advantage that the part scan be reused in other proxies. This is also the way to enable testing for these parts. 

Design for testability

The sequences are the basis for the testability of WSO2 ESB proxies. The following design guidelines and steps can be used for testing your proxies.
  1. Configure separate testable parts within a separate sequence
    A good guideline in splitting is that the parts should be as independant as possible from other parts. Good examples are: input validation, data transformation, sending a message to an endpoint, a step within an iteration.

  2. Define a separate developer studio project for the test proxies
    This will be the proxies that will contain a testable sequence and can be called from soapUI for example. This way also the test package can be deployed separately. This way the test project is not deployed on production.

  3. Define a soapUI project for testing the component
    It is wise to define a separate soapUI project for each component (WSO2 proxy) you want to test. Note that this can also be used within a Continuous Integration environment for automatic testing.

Example

The following is an example in which a data transformation is tested.
Step 1 – Define data transformation in a separate sequence



  
Step 2 – Define separate ESB project with test proxy
Note that the sequence is referenced and the result of the sequence is returned with respond mediator.
This result can be checked within soapUI using Asserts later on.

 


Step 3 - Define a soapUI project with test cases
In the request message put a soap message as expected by the sequence. Note that the ESB uses soap as its common message format within the mediation. The response can be checked with assertions.
Request



Response





Conclusion

The sequence split can be used to configure testable parts within a WSO2 ESB implementation.

This may not always be easy todo but hopefully you can use it to test your ESB implementations.
Feel free to comment on this blog ! All feedback is welcome

Reacties

  1. Splitting into named sequences and creating a separate ESB project for testing sounds like a good concept. I would like to see examples of how you would set up tests for more complex scenarios like splitting an incoming message into multiple new messages.

    BeantwoordenVerwijderen
    Reacties
    1. Hello Wouter,
      Thx for the feedback.

      W.r.t the split, i assume you mean an Iterator? I would put the handling of each iterator within a sequence and test the sequence. So that you test that at least each step will work.

      Verwijderen
    2. Yes, the iterator is the mediator i was thinking about. To be more specific: i have an iterator that splits the original message in multiple messages. For each sub-message i will apply an Xslt transformation and then a filter mediator is used to put some of the messages on a queue for further processing.

      Verwijderen
    3. I put XSLT in sequence, filter in sequence, and putting the message on Queue in a separate sequence.
      PS I do not know the context and functionality but why letting the "publisher" do the filtering?

      Verwijderen
    4. That still will not test the most essential part of the whole sequence: splitting the original message. I can test XSLT-transformations with regular unit testing frameworks like XUnit and putting a message on a queue is part of the infrastructure.

      Good point about the filtering. I should negotiate with the receiving party to do the filtering themselves.

      Verwijderen
    5. Ok but what is the essential part of the splitting? What is complex about the splitting?

      Verwijderen
    6. Splitting is not complex, it's just an xpath based iterator. Point is, if there is an error in the xpath, i will miss messages. When a transformation if wrong, it will result in an error and it will be logged. When the iterator select to few messages because of a faulty xpath it will not be logged. That's why it is essential to test the iterator.

      The way i should approach it, is to create a test proxy that executes the sequence containing the iterator and route all calls to a mock service. The mock will need to keep track of the number of calls, so in the end i can verify if the number off call equals the expected count.

      Verwijderen
    7. When a transformation is wrong w.r.t. (correct) xpath it will also not result in an error b.t.w. ;-)

      With respect to testing: it of course also depends on how detailed and complete you want to test. Maybe in case of an XPath you could just check with XSLT editor.

      Verwijderen
  2. Thanks and Regards. Oracle Apps R12 Training Videos at affordable cost. please check oracleappstechnical.com

    BeantwoordenVerwijderen

Een reactie posten

Populaire posts van deze blog

Microservices mindmap

"The tree" - See also   my photo page When you are fairly new within the Microservices land, there are a lot of terms fired at you. So also for my own understanding i have made a mindmap. I think it has a good status now, so that i can share it with you. As always feedback is very welcome ! You can download the mindmap here .

Book review: Data Management at Scale (Piethein Strengholt)

 This blog is a review of the book "Data Management at Scale (See also at bol.com ) Data Management is a hot topic nowadays and this book does a fantastic job at adding value to this topic. It is a must read and one of the few technical books I finished reading in a weekend. The book gives a fantastic overview on how to implement a Data Mesh data architecture. The Data Mesh concept is explained by Martin Fowler here . The book is a good mix between conceptual and implementation architecture level. It gives a lot of examples of how this architecture at scale can work, for both small and big companies. It is practical and I used it to implement it at one of my customers. The book describes an architecture in which the focus is on the DIAL (Data- and Integration Access Layer).  On a high level the book covers the following topics: The key principles for data management at scale - Domain-Driven Design  - Domain Data Stores - Meta data management Ready Data Store The concept of servin

DApp, DeFi, CAKE, PancakeSwap and the Binance Smart Chain

DApp, DeFi, CAKE, PancakeSwap and Binance Smart Chain are all hot terms that are popping up more often within the crypto world. I am newby in this world, but also it has my curiosity in this Corona time. I tried some of the DeFi app and have written some articles about it on my Medium account. You can read about How to use and deposit tokens within PancakeSwap (a beginners guide) How to setup a MetaMask wallet What is "impermanent loss" when you invest in liquidity pools? First I will explain some of the terms used. DApp = A decentralised application within DeFi land. A finance application where you can buy and lend liquidity in a decentralised way. DeFi = Decentralised Finance.  BSC = Binance Smart Chain. This is the network that Binance uses for its BEP-20 tokens APR = Annual Percentage Rate. The percentage you will receive in a year. For example when you deposit 1000$ with an APR=10%, you will receive 100$ at the end of the year APY = Annual Percentage Yield. The annual