Service Virtualization

  • 1.  TDM Excel Approach is not working in Devtest10.3 version

    Posted Mar 05, 2019 07:04 AM

    Hi,

    I am using LoadTDMDataStore step in VSM to read data from excel file and pass values in the response.

    This feature is working fine in Devtest9.5 version, however, in devtest10.3, i am seeing below error in vse.log file.

     

    javax.script.ScriptException: bsh.TargetError: Sourced file: inline evaluation of: ``//Assessor Scenario 1 import com.itko.tdm.framework.builder.query.*; import co . . . '' : Method Invocation DS_Name.query : at Line: 7 : in file: inline evaluation of: ``//Assessor Scenario 1 import com.itko.tdm.framework.builder.query.*; import co . . . '' : DS_Name .query ( testExec , "scenarioOne_New" , query )

    Target exception: java.lang.NoSuchMethodError: org.apache.poi.POIXMLDocument.hasOOXMLHeader(Ljava/io/InputStream;)Z
    in inline evaluation of: ``//Assessor Scenario 1 import com.itko.tdm.framework.builder.query.*; import co . . . '' at line number 7
    at bsh.BshScriptEngine.evalSource(BshScriptEngine.java:97)
    at bsh.BshScriptEngine.eval(BshScriptEngine.java:61)
    at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
    at com.itko.lisa.test.ScriptExecHandler.executeScript(ScriptExecHandler.java:674)
    at com.itko.lisa.test.ScriptExecHandler.executeScript(ScriptExecHandler.java:427)
    at com.itko.lisa.vse.stateful.model.RequestMatcher.evaluateScript(RequestMatcher.java:138)
    at com.itko.lisa.vse.stateful.model.RequestMatcher.matches(RequestMatcher.java:108)
    at com.itko.lisa.vse.stateful.model.Request.matches(Request.java:427)
    at com.itko.lisa.vse.stateful.model.Request.matches(Request.java:401)
    at com.itko.lisa.vse.stateful.TransactionNavigator.deterministicSingleThreadFind(TransactionNavigator.java:186)
    at com.itko.lisa.vse.stateful.TransactionNavigator.findTransaction(TransactionNavigator.java:166)
    at com.itko.lisa.vse.stateful.TransactionNavigator.findMatchingSpecific(TransactionNavigator.java:522)
    at com.itko.lisa.vse.stateful.TransactionNavigator.getRespondingTransaction(TransactionNavigator.java:473)
    at com.itko.lisa.vse.stateful.TransactionNavigator.getStatelessResponses(TransactionNavigator.java:630)
    at com.itko.lisa.vse.stateful.ConversationalStep.execute(ConversationalStep.java:516)
    at com.itko.lisa.test.TestNode.executeNode(TestNode.java:984)
    at com.itko.lisa.test.TestCase.execute(TestCase.java:1297)
    at com.itko.lisa.test.TestCase.execute(TestCase.java:1198)
    at com.itko.lisa.test.TestCase.executeNextNode(TestCase.java:1183)
    at com.itko.lisa.test.TestCase.executeTest(TestCase.java:1124)
    at com.itko.lisa.coordinator.Instance.run(Instance.java:208)
    Caused by: java.lang.NoSuchMethodError: org.apache.poi.POIXMLDocument.hasOOXMLHeader(Ljava/io/InputStream;)Z
    at org.eobjects.metamodel.excel.ExcelDataContext.getSpreadsheetReaderDelegate(ExcelDataContext.java:180)
    at org.eobjects.metamodel.excel.ExcelDataContext.getMainSchema(ExcelDataContext.java:147)
    at org.eobjects.metamodel.QueryPostprocessDataContext.getMainSchemaInternal(QueryPostprocessDataConte

     

    I am using below logic in match script and kept  lisa-ext-ddvs.jar , MetaModel-excel-3.2.1.jar , MetaModel-core-3.2.1.jar, MetaModel-xml-3.2.1.jar and MetaModel-full-3.2.1.jar in lib folder.

    In the response image i am using syntax as '<AcctId>{{scenarioOne_ILATWO}}</AcctId>. Here 'scenarioOne' is sheet name and ILATWO is column name in that sheet.

     

    import com.itko.tdm.framework.builder.query.*;
    import com.itko.tdm.framework.dto.*;
    TDMQuery query = TDMQuery.create(Table.name("scenarioOne"));

    query.whereArr(new WClause[]{new WClause("scenarioOne", "ILATWO",request_SOAP_Envelope_SOAP_Body_AcctInqRq_AcctSel_AcctId_text_.toString())});
    return DS_Name.query(testExec, "scenarioOne",query);

     

    Please let me know any suggestions to overcome this issue.



  • 2.  Re: TDM Excel Approach is not working in Devtest10.3 version

    Posted Mar 07, 2019 08:42 AM

    This exception indicates you are using a custom extension (lisa-ext-ddvs.jar) and other custom libraries (jars), all of which are not supported by the product and contain features largely unknown to most of the community. 

    What version of the poi-ooxml JAR are you using in DT 9.5?  

     

    DT 10.3 uses poi-ooxml-3.17. See LISA_HOME\shared\poi-ooxml-3.17.jar. Take care if you choose to downgrade to a prior poi-ooxml-3.x.jar. That could have unintended consequences.



  • 3.  Re: TDM Excel Approach is not working in Devtest10.3 version

    Posted Mar 07, 2019 11:25 PM

    Thanks for the reply Joel.

    I am using poi-3.7.jar, poi-ooxml-3.7.jar and poi-ooxml-schemas-3.7.jar files in Devtest 9.5

    Just to test, i kept these jar files in DT 10.3 (LISA_HOME\shared\ )folder instead of 3.17 version files. I am getting expected response.

    Not sure about the consequences of using old version of poi jar files in DT 10.3.

    If you could let me know what changes to be done in latest jar files it would be really helpful. For now i will use old jar files.



  • 4.  Re: TDM Excel Approach is not working in Devtest10.3 version

    Posted Mar 08, 2019 04:13 PM

    I am glad you confirmed the issue. In this case, DevTest shipped the poi-3.17.jar for some reason which probably means that it is used somewhere in the product -- for what reason and in what capacity I do not know.

     

    My guess is that you need to modify classes inside the custom lisa-ext-ddvs.jar that invoke POIXMLDocument hasOOXMLHeader to use the replacement feature exposed in the poi-3.17.jar. I have no idea what those changes might be since this is a custom JAR file created for your customer.

     

    As a best practice, it is not recommended that customers downgrade (or upgrade, for that matter) JAR files that are distributed with DevTest. You could be setting yourself up for an unintended consequence. In most instances, CA Support, when diagnosing DevTest issues, has no way of knowing that someone has replaced JAR files with other versions. This can create a lot of extra work for a perceived defect that was introduced by the software purchaser not the vendor.

     

    About the only DevTest supplied JARs that I see 'swapped' are the older JDBC driver JARs. These JARs are usually dependent on the version of the DBMS not DevTest; hence the swap is necessary to get a connection to work properly.