Service Virtualization

we have a 'service' that is file based..  we ftp and place a file in a providers system, they process it, and later we come back to get the processed output.

we need to simulate the provider.

we wrote a test to do this, as its not transactional.

step 1, check if there is a specific type of file (the request)

step 2, read excel file, for each row, get the id info, and generate a new set of row content, append that to a new file (the temp response )

step 3, rename the temp response to the correct name

step 4, erase the input file. (we have processed it)

we use the data source read excel file for step 2.

but we have three problems

1. there is no header row over the columns on this file. it is a known format.

    so before the builtin function can read this file, we have to pre-pend a header row.. sheesh you make it hard..

2. the name is not the same each time the test runs (every 10 minutes), but the 'read excel file' data source evaluates the name as SOON as the service starts, and does this only once.

    in our case the name changes for ever iteration

3.. when we are done, and need to delete the input file.. we cannot, because it is still open..

    if we delete a file we have never touched, it works fine.

we don't see a close file operation..

anyone have any pointers on how to solve either of these problems?

we could of course write all this in groovy, and not use any of the DT functionality (again).. but we are trying to use the product.

I know the DT product team doesn't call this a 'service' but it is exactly the same, it allows us to disconnect from our dependencies for test.

this service takes approx 4 minutes to execute

and on top of all that , Workstation (running v 8.5) keeps crashing, hanging, after like three iterations of this in ITR..

almost cannot make progress..  took two of us to get to this spot yesterday, and we are the advance team.

Sam, I have no idea if this will help or not.  Maybe there is a method on the DataSet class that could be used...  I am unaware of any documentation on the items below:

import com.itko.lisa.test.DataSetManager;

import com.itko.lisa.test.DataSet;

DataSet ds = DataSetManager.findDataSet(testExec,"YOUR_DATASET_NAME");

ds.destroy();      <-- I wonder if this operation will release your dataset so you can delete it?      

No idea if any of these methods might do to help you...

ds.reset();            <-- I believe this resets the counters so you don't hit EOF prematurely

or ds.initialize( ... )   

or ds.cancelProcessing()

thanks..   we think this is actually a bug..

if we have a dataset read block IN the tst but NOT actually used.. it opens the file immediately on itr start.. but never closes it..

you actually have to close the project in workstation to get it to release the file..

this service was initially written by CA services in 8.0.1, so this supports that there is a bug now..

we ended up not using any of the datasource blocks..  cause it just doesn't work.

and another thing.. if you open a file in a tst itr and the run fails.. nobody cleans up the open files..

oh the fun of running in the same process space..

1. there is no header row over the columns on this file. it is a known format.

    so before the builtin function can read this file, we have to pre-pend a header row.. sheesh you make it hard..

-> indeed. When reading a row DevTest need to map the values to properties, and the properties names are given by the header row otherwise how can DevTest figure out the names of the properties to map into the values ?

2. the name is not the same each time the test runs (every 10 minutes), but the 'read excel file' data source evaluates the name as SOON as the service starts, and does this only once.

    in our case the name changes for ever iteration

-> where is the file name coming from ? you can use a property instead of hard coded SOON value

3.. when we are done, and need to delete the input file.. we cannot, because it is still open..

    if we delete a file we have never touched, it works fine.

-> I had the same issue. Try to run your test locally or remotely to see if the problem persists.