Home/ Questions/Q 8842097
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-14T10:52:49+00:00

In my attempt to load information from the analytics engine, I have been unable

  • 0

In my attempt to load information from the analytics engine, I have been unable to load custom fields. In particular, I am looking to load information belonging to Portfolio Items. There are some fields that return OIDs, such as State, that I am able to hydrate in the analytics scenarios doc, but am unable to hydrate through the SDK. In fact, I am unable to retrieve any State values. It also seems that, while an OID is returned for InvestmentCategory, it is the same for every record, and hydrates to “None”.

I am wondering how mature this portion of the SDK is, and/or if there are extra parameters that I am just missing? Do custom fields still need to be prefixed with “c_”? I have tried specifying them with and without the prefix with no luck.

EDIT1: It seems I just needed to increase the limit. I am seeing values returned for custom fields, which are prefixed with “c_”. I will post back with another update, when I have verified that it was just early records that left me confused. The hydration “issue” still stands. I am only seeing InvestmentCategory being hydrated.

EDIT2: Indeed, the “issue” was that, over time, the set of required fields changed, and older records did not have some fields, such as Investment Category, specified/defined. The hydration issue with the State field still remains, and I hope to hear back from Mark when there is an update. I hope that there will be updates that will allow hydration of more fields in the future.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I work at Rally Software as part of the team that built the Lookback Api. I’ve just tested this out, and it seems to work for PortfolioItem InvestmentCategory fields, but only partially for State, so I think you’ve found a problem.

    To confirm that you have PortfolioItems with an InvestmentCategory other than “None”, you could try the following query:

    https://rally1.rallydev.com/analytics/v2.0/service/rally/workspace/<YOUR WORKSPACE OID HERE>/artifact/snapshot/query.js?find={_TypeHierarchy:"PortfolioItem",InvestmentCategory:{$ne:"None"}}&fields=["InvestmentCategory"]&hydrate=["InvestmentCategory"]

    Similarly, if you try it through the SDK your SnapshotStore config should look something like:

    {
    context: {
        workspace: this.context.getWorkspace(),
        project: this.context.getProject()
    },
    rawFind: {
        _TypeHierarchy:"PortfolioItem",
        InvestmentCategory:{$ne:"None"}
    },
    fetch: ["InvestmentCategory"],
    hydrate: ["InvestmentCategory"]
}

    You can verify the raw results of your query in the debugger by checking the server response in the browser’s debugger.
    In Chrome if you go to the ‘Network’ tab you should see an entry for ‘query’ which you can either look at in the ‘Response’ tab on the right or, (as I prefer to do) right-click it and choose ‘Open Link in new tab’. If you use the Chrome extension “JSONView and JSONLint for Google Chrome” (https://chrome.google.com/webstore/detail/jsonview-and-jsonlint-for/mfjgkleajnieiaonjglfmanlmibchpam) it also makes it much easier to read.

    For the field State on PortfolioItem, I think you’ve found a defect. I’ve entered this as DE15305 to be investigated. I’ll post back here when we know more.

    edit:

    Yes, we allow you to use the string version of type names in _TypeHierarchy and then resolve them to the underlying OIDs. In theory using OIDs should be fractionally faster, so if you’re getting it from a type-picker great, but if you’re hard-coding them then using the strings for readability should be fine. You’re correct about PortflioItem types as well, you can search for “PortfolioItem/Strategy”, “PortfolioItem/Feature” etc (depending on if they’ve been renamed in your workspace). Using OIDs does have the benefit of insulating you from renames.

    Query filters should support everything that rawFind does, it’s just a question of if you prefer the ExtJS-style syntax or the native Lookback API/MongoDB-style syntax. The performance difference between the two should be negligible (although I admit, I haven’t tested this in a micro-benchmark).

    The defect is still in the backlog to be investigated, but the current theory is that it may have been for a State that was deleted, and we can only hydrate values using the current values – we use “the lens of today” for these foreign keys. There’s a chance this may change in the future, but I can’t promise anything, sorry. I’ll update again when the defect is picked up.

    • 0