Skip Navigation LinksForums > SpiraTeam Forums > SpiraTeam Issues & Questi... > Formulate a grouped SOAP-...

Formulate a grouped SOAP-WSDL query to retrieve all the requirements' comments/test cases coverage at once RSS Feed

Friday, September 12, 2014

I was wondering if it was at all possible to retrieve all the comments for every requirement in a project in a single SOAP query?

Right now I'm doing a Requirement_Retrieve(startingRow=1, rumberOfRows=99999), iterating every requirement, and then using the Requirement_RetrieveComments(req_id) method to get the list of comments for every requirement.
This means for the 600 something requirements in the project I'm working with, it has to open a connection, do the ssl handshake, etc. It's a bit slow.

If I could retrieve the comments along with my Requirement_Retrieve query, I could parse it all using XPATH and it'd take seconds instead of minutes.

By the way, what is this 'Comments' property name listed here: ?
I don't see this property appearing anywhere in my Requirement_Retrieve query response.

I'm also facing a similar performance problem when trying to retrieve all the test cases covering the requirements: I found no better way than issuing a Requirement_RetrieveTestCoverage(req_id) for every requirement.

Thanks in advance!
4 Replies
Adam SAdam S
re: Maxim Cournoyer on Friday, September 12, 2014
Friday, September 12, 2014

Hi Maxim

No I'm afraid it is not possible.

The issue is actually that to grab that much data in one go would exceed the 90 second timeout for a web service query. That's why the API is structured that way.



Maxim CournoyerMaxim Cournoyer
re: Adam S on Friday, September 12, 2014
Friday, September 12, 2014
Hello Adam,

Thank you for your prompt response.

Do you mean that the webserver would exceed the 90 seconds timeout just to prepare the data?
Or do you mean that it would take more than 90 seconds for the client to download the data? Or both?

The Requirement_Retrieve method already sends a lot of data (about 10 MB worth of XML for this project IIRC), and does so in less than 5 seconds in our environment. I doubt we'd ever hit the 90 seconds limit except for very large projects or very slow connections.

What imposes this 90 seconds restriction anyway? I'm guessing the IIS server? If so, it seems it can be trivially changed as explained here:
Jon FreedJon Freed
re: Maxim Cournoyer on Friday, September 12, 2014
Monday, September 15, 2014
We have a similar requirement for data within a project.  We are handling it through a report with multiple custom sections.  Essentially one section per data entity, e.g. one section for requirements and one section for comments.  The first section's XSLT includes script tags in the output, including a script tag to include jQuery.  We have custom script that utilizes jQuery and joins together the separate sections of data for a cohesive presentation of data to the user.

Here is our tree-like structure that we're working towards developing.  Each bullet point represents a section of rows in the output.  We're not entirely comfortable with this structure, but it's a starting point for development.  The goal is to have a report that can be quickly generated and then used during meetings to talk through current status.  This has proven unfortunately necessary because the user interface is just too slow to navigate through during meetings where we don't want participants to be waiting on SpiraTeam.

  • Releases & Iterations
    • Comments (within two sections: less than 8 days old and a collapsible section with comments older than 8 days)
    • Tasks & Incidents (together, through a Entity union operation), currently sorted by Start Date then End Date
      • Comments (same structure as above)
    • Requirements
      • Comments (same structure as above)
      • Tasks & Incidents (same structure as above)
        • Comments (same structure as above)
  • Requirements (across Releases and Iterations)
    • Comments (same structure as above)
    • Tasks & Incidents (same structure as above)
      • Comments (same structure as above)
Believe it or not, the report can be executed in seconds, and even under a second at times.  The report execution is probably eased by the general lack of joins.  Also, the jQuery-facilitated organization of the report output is similarly quick.  The longest part of the process is waiting for the browser to load the data and the jQuery library so that the custom script can start executing.  Your experience may be quite different of course due to your different data.
Maxim CournoyerMaxim Cournoyer
re: Jon Freed on Monday, September 15, 2014
Sunday, September 28, 2014
Jon Freed, thank you for taking the time to share your solution. It might come in handy!
  • Started: 9/12/2014
  • Last Reply: 9/28/2014
  • Replies: 4
  • Views: 1014
Powered by KronoDesk v1.1.0.15 | © Copyright Inflectra Corporation 2011-2016 | Licensed to Inflectra Corporation.