Rally Software

Expand all | Collapse all

Database Connector (Postgres) - Options for Conflicting Portfolio Item

Jump to Best Answer
  • 1.  Database Connector (Postgres) - Options for Conflicting Portfolio Item

    Posted 12-19-2018 01:02 PM



    I am running into an issue with the CA Agile Database Connector for Postgres. We have a conflict in one of our Portfolio Item Types and another object that was introduced into the product - Investment. I see in the documentation for the connector that this is a constraint that is not supported but I was trying to figure out my options. The obvious would be for us to rename our Portfolio Item but that is not really a possibility, as there would be numerous other downstream issues with that approach in our environment. The workaround that I had hoped would be an option was to move up to the base PortfolioItem object and filter on PortfolioItemType.Name. This approach works partially, but does not want to return all the attributes I am specifying. Specifically, I can't get the base PortfolioItem object to return the Parent or the State.


    Here is what I am attempting to return in the config file:




    I have attached 2 snippets of logging. One shows the unsuccessful attempt with the base PortfolioItem object. You can see where it attempts to grab the State mapping, but doesn't return the values, and also that it dropped Parent altogether - it should be between PlannedEndDate and PortfolioItemTypeName.


    The second shows a successful pull that I made with a non-conflicting Portfolio Item type. In it, you can see that it grabs the right State mappings and also does not drop out the Parent.


    Thanks in advance!


  • 2.  Re: Database Connector (Postgres) - Options for Conflicting Portfolio Item
    Best Answer

    Broadcom Employee
    Posted 12-19-2018 06:03 PM

    Hi Michael,


    I'm afraid the options are pretty limited there.  PortfolioItem is a more primitive form of the object that the actual PI type extends and, as you've discovered, conflicts in PI name with endpoint names causes issues there as well.


    I'm not sure there's really a good answer to this one.  I've run into similar situations with other customers and in the end our only option was to rename the PI type.