This is an IBM Automation portal for Cloud Platform products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
Thank you, need to check with development team
Let me try to re-explain. In our case, it's possible that other tools rely on UrbanCode Deploy to do deployments. In order to be able to do general reporting, we add certain properties as metadata as part of the deploy to the Application Process properties.
During the reconciliation phase, we generate a report based on all the deployments that have been done as part of UCD. To get a list of all deployments for a particular timeframe, we rely on:
https://www.ibm.com/docs/en/urbancode-deploy/7.1.1?topic=ar-get-information-about-all-application-process-requests-server
The above request returns a lot of information, including the root trace of the deployment. This is a very huge object (100 records result in a response of 18MB). Yet, it doesn't return the properties of the deployments, which we require to pull out the metadata. So, maybe it makes sense to make the exposing of this root trace optional, to lower the size of the response + stress it puts on the database.
So, in order to fetch these application process deployment properties, we make a call to https://www.ibm.com/docs/en/urbancode-deploy/7.1.1?topic=resource-applicationprocessrequestinforequestidproperties-get to retrieve this information. This works fine. An improvement here would be if it would be possible to specify one or more properties which we're looking for. If we only need the value of 1-5 properties, it's a bit wasteful to get all properties.
Keep in mind that if we generate the report for a complete month (with 1000's or 10000's or 100000's of deployments), that's a lot of traffic for no benefit.
So, we see two improvements from a performance perspective:
Make the exposure of the root-trace object optional. If you only want to get an overview of the deployments, this is way too much information
Give the flexibility to get the value of an individual property or multiple, but not all
Bonus: the first api has the option 'startedAfter'. It would be good to include a 'startedBefore' so that you can query for a timeframe (start-end). Now, the consumer of the api needs to foresee custom logic to stop requesting the next x amount of records when the 'startedBefore' values has been exceeded.
Could you please give a more detailed description of what you try to achieve?
Do you want to have the provided arguments for resoure-run-application-process also shown in the ar-getinformation-about-all-application-process-requests-server?