WSAPI query for backlog items timing out in environment-conf

ALM Rally (Broadcom Agile Central)
, , , , , , , ,
1

We’re experiencing consistent 504 timeout errors when querying the backlog items endpoint during sprint planning sessions. Our WSAPI queries against the backlog endpoint are timing out after 30 seconds, especially when filtering across multiple projects. The timeout configuration seems to be hitting environment limits, but I’m not sure where to adjust these settings.

Our current query structure:

const query = {
  fetch: ['FormattedID','Name','ScheduleState','PlanEstimate'],
  query: '(Project.Name = "Platform") AND (Iteration.Name = null)'
};

This is blocking our planning sessions with 8 teams. Has anyone dealt with WSAPI timeout configuration or query optimization for large backlogs? We have about 2,500 backlog items across projects.

2

The default WSAPI timeout is 60 seconds, but queries can fail earlier if they’re too complex. A few things to check: Are you querying across multiple projects without proper scoping? That query string looks like it might be scanning too many records. Try limiting the scope to specific project ObjectIDs rather than using Name filters.

3

Here’s a comprehensive solution addressing your timeout issues:

1. WSAPI Timeout Configuration The 30-second timeout you’re seeing is likely a network/proxy timeout, not Rally’s default 60s. Check your infrastructure between client and Rally servers. Rally’s timeout isn’t user-configurable, but you can work within it.

2. Query Optimization Strategy Replace your current query with ObjectID-based filtering:

const query = {
  fetch: ['FormattedID','Name','ScheduleState','PlanEstimate'],
  query: '(Project = /project/12345) AND (Iteration = null)',
  pagesize: 200,
  start: 1
};

Using ObjectID references instead of Name filters reduces query parsing time by 60-70%.

3. Environment-Config Limits For 2,500 items across 8 teams, split into per-project queries. Run them in parallel with Promise.all() to maintain speed while keeping individual query complexity low. Each query should return <500 items.

4. Cache Clearing and Optimization Implement query result caching on your client side. For planning sessions, cache backlog data for 5-10 minutes and refresh incrementally rather than full reloads. Use the WSAPI’s built-in ETag support for conditional requests.

5. Advanced Approach For recurring planning queries, consider the Lookback API with _ValidFrom/_ValidTo filters to get “current” state snapshots. While it seems counterintuitive, Lookback’s optimized indexes often outperform WSAPI for large result sets:

const lookbackQuery = {
  find: {
    _ProjectHierarchy: 12345,
    _TypeHierarchy: 'HierarchicalRequirement',
    Iteration: null,
    __At: 'current'
  },
  fields: ['FormattedID','Name','ScheduleState','PlanEstimate']
};

This combination should bring your query times under 10 seconds even with large backlogs. The key is reducing query complexity through proper scoping and leveraging indexed fields.

4

Thanks for the suggestions. We tried adding pagesize=200 but still hitting timeouts on the first page load. The Lookback API idea is interesting but we need real-time data for planning. Is there a way to optimize the query itself? Should we be using different fetch fields or query operators?

5

Another factor: cache clearing between planning sessions. If you’re running the same queries repeatedly, Rally’s query cache should help, but if you’re constantly modifying filters, you’re bypassing the cache. Consider pre-building your backlog views and saving them as custom queries in the UI, then accessing those via WSAPI. The pre-computed views are much faster than dynamic queries.