Forum Discussion

ameesh1984's avatar
4 years ago

Can soap ui or ready api test persistance layer what are the options available ?

We have a requirement to test persistence layer, can soap ui or ready api test it ?

  • richie's avatar
    4 years ago
    Hey ameesh1984,

    Ok so you have what you term green screen back end (what is that...some sort of mainframe/mini computer?), some asynchronous messaging in which messages are published to a Kafka topic (the messages are transformed via an adaptor component in your Kafka I.S.) and these transformed messages are then posted to cosmosDB's listening REST API to persist the message in the DB.

    Is that i understand correctly?

    That sounds analagous to a number of the projects ive worked on in the past (albeit different technologies, so ive never used Kafka before but ive used TIBCO, Weblogic, WSO2, Mulesoft).

    If i understand correctly then id say its perfectly possible (it sounds like a lot of my previous projects)

    So what have you gotta verify...the whole thing? So in this instance, the 4 points for possible consideration are:

    1=ETL process to generate message from greenscreen mainframe
    2= transformation,
    3=schema valid messages consumption by rest api,
    4=db write of schema valid messages.

    1. ETL process (daily batch job?) executes extracting data from its on premise database into some sort of flat file (.csv? .xml? Tab separated? Fixed width?) and

    2. Flat file messages published to the topic are transformed correctly (due to defined transformation rules which youd verify) and

    3. the transformed messages are then posted via the cosmos db .wsdl/.wadl (.xsd/.json schemas so messages need to be schema valid) endpoint, which youd verify and

    4. Webservice consumed messages written to the db correctly (transaction type works correctly, so create/update/delete of data records work correctly) and message content needs to be written to db table(s) correctly, so message attributes' values are written to correct table attribute, no invalid data is attempted to be written (no text attempting to write to numeric fields, any blank attributes in message correspond to null allowed table attributes, field atteibutes are correct length so no values are truncated).

    Sorry. I know i go on a bit. Im just a bit too literal sometimes so i have to explain my understanding to ensure i understand what youre talking about before i can try and help.

    I know nmrao has more experience of using the JMS components of soapui than me (i'm thinking about the Kafka topics at this point. Does Kafka use JMS?). Ive always avoided using the JMS/Hermes functionality in soapui in my projects that use asynch queues/topics cos theres no response to assert against so the way ive always done it is for dev to code a stub that hooks into the api on the queue/topic (to enable me to verify the adaptor transforms the messages correctly), so you dont have to use the JMS functionality....the additional stub approach is more work for dev however, but less work for me.

    Anyway. Thats all i got for now. I hope some of that essay helps!


4 Replies

  • nmrao's avatar
    Champion Level 3
    Would you add specific details on what you need to test, such as database etc?
    • richie's avatar
      Community Hero
      Hey ameesh1984,

      Is this related to your previous post for cosmosDB?

      When you ask can soapui/readyapi! test the db layer, can you clarify what are the requirements for the testing....what would you be trying to verify?
      Last year i had to verify a new Reference Data System (via an API gateway) which would be used for multiple different systems. The requirements included data quality and certain data attributes which required a little more planning and forethought (and a lot of groovy - all courtesy of Rao by the way.....i never could of done it without Rao's help in fact), but it was achievable.

      So to summarise. Can you clarify what you actually want to verify via your DB testing and then people will be able to provide more concise answers.


      • ameesh1984's avatar
        The persistent layer for us is a data transformation layer converting data from a green screen backend via Kafka topics into azure cosmos DB