I am trying to obtain Iteration Cumulative Flow object fields through WSAPI via Java. For some reason, I get blank values for IterationObjectID. Do you know how to resolve it?
It seems that the IterationObjectID attribute is not being returned when querying the Iteration Cumulative Flow object via WSAPI 1.43 or earlier. However, you can retrieve this same attribute when querying the Iteration Cumulative Flow object via WSAPI 2.0. Rally Support is currently investigating this matter.
Related
Can any one suggests the best way to page through an API in Mule 4? The examples I saw used a choice with a flow reference to call the flow again in a loop. This API doesn't return the total number of records or pages so need to loop through each page until it returns an empty payload.
But if I call the same flow recursively, its throwing too many child context error.
What is the ideal way to handle this scenario?
I faced same kind of scenario recently. I have done a recursive call using another flow to call the parent flow. If you use a flow reference from the same flow it will not allow you to do so.
In the child flow, I have incremented the next start index as well.
If you are looking for paging from the API level, you can accept the start index and the Page size as the two parameters. This call can go until the number of records < page size OR the API returns 0 records.
I am getting doctorCodes as (Dr1124914 ,Dr1074955).
My clinic API gives above response taking one doctorCode a time ,I have to extract a value from my response.
But I want to make parallel calls to my API with all values of doctorCodes as shown above in one go , extracting required field from it
and accumulating finally to my resultant payload .
You can use the Scatter-Gather component to perform parallel calls and aggregate the results using DataWeave. See the documentation at https://docs.mulesoft.com/mule-runtime/4.1/scatter-gather-concept
Note that it works for a fixed number of parallel way, not for dynamic routes. I don't think there is no way to do a dynamic number of routes in Mule 4. If you are interested in that you would have to implement it by yourself in custom Java or scripting code somehow.
I have a requirement in hand where I need to change the Mule Flow Threading Behavior at runtime without the need of bouncing the whole Mule Container. I figured out few different ways to achieve this, but none of them are working.
I tried accessing the Mule Context Registry and from there I was trying to do a lookup of "FlowConstructLifecycleManager" Object so that I can tap in there and access the threading profile of the object and reset those values, then stop and start the flow programmatically in order to get the change applied in the flow. I am stuck in this approach as I was unable to get hold of the FlowConstructLifecycleManager Object neither from the Mule Spring Registry nor from the Transient Registry. I was able to get hold of the Flow object though which has a direct reference to that FlowConstructLifecycleManager Object. But, unfortunately, they made this object as protected and didn't expose any method for us to access this object.
Since I was unable to access this FlowConstructLifecycleManager directly from Mule implemented Flow class, I decided to extend this Flow class and just add another public method to it so that I can access FlowConstructLifecycleManager object from Flow object programmatically. But, I am stuck in this approach as well as even if I am putting my version of the same Flow class packaged and dropped in lib/user folder of the container, it is still not picking up my version of the class, and loading the original version instead.
It would be of great help if I can get any pointer on the approach of solving either my first or second problem.
Thanks in advance,
Ananya
In our company, we are building a dashboard from where we should be able to start/stop any flow or change the processing power of any flow by increasing/ decreasing the active threads for a flow or changing the pollen polling frequency. All of these should be done at runtime without any server downtime.
Anyway, I made it working finally. I had to patch up the mule-core jar and expose few objects so that I can get to the thread profile object and tweak the values at runtime and stop/ start the flow to reflect the changes to take effect. I know this is little bit messy and but it works.
Thanks,
Ananya
I have been using DeleteByQueryRaw to successfully delete index objects but now I have updated to 0.12 it is missing. Is there a replacement 'raw' method of calling ES to delete in the new version?
Can you use the Delete By Query method that is part of 0.12, perhaps coupled with the DeleteByQueryParameters object to achieve the same results of using the previous DeleteByQueryRaw?
Update:
Appears that the forthcoming Elasticsearch.Net, which the next version of NEST will be built upon, will support/expose the entire ES API.
Elasticsearch.Net maps all the Elasticsearch API endpoints to methods.
See Elasticsearch.Net Building Requests for more details.
So based on this, you should be able to still do a 'raw' delete request using Elasticsearch.Net.
I need a good example of using the LookbackAPI to get the data for a burn up chart. I see some limited questions and responses on the API but no examples on how I would use it to do so. I need to get the current scope on story points and story points completed.
Sorry for the scarcity of available examples. More and better examples will be coming as the LBAPI beta matures. I'd definitely recommend that you become familiar with the Lookback API (LBAPI) Documentation, as there are good examples there for formulating queries.
For a burnup, let's say you want to get the state Snapshots for an Iteration going from 15-Jan-2013 through 30-Jan-2013, and that the Iteration applies to a Project hierarchy that is four-deep. The following LBAPI query would obtain the PlanEstimate, ToDo, and Schedule State for Stories scheduled into that Iteration:
{
find:
{
_TypeHierarchy:"HierarchicalRequirement",
Children:null,
_ValidFrom:{
$gte:"2013-01-15TZ",
$lt:"2013-01-30TZ"
},
Iteration:{
$in:[
12345678910,
12345678911,
12345678912,
12345678913
]
}
},
fields:[
"PlanEstimate",
"ToDo",
"ScheduleState"
]
}
Where:
$in:[
12345678910,
12345678911,
12345678912,
12345678913
]
Are the ObjectID's of the Iteration called "Iteration 1". It's probably easiest to get these Object ID's from a standard WSAPI query on Iterations: (Name = "Iteration 1"). For Iterations copied into a four-deep project hierarchy, we would see the four Iteration OID's similar to the above.
For charting, the toughest part right now is an easy way to deal with the Time-Series data. The most robust way to query and process LBAPI data currently is by working directly against the REST endpoint and processing the returned JSON results in your own code.
With Javascript apps, for processing the data and turning it into a Chart, the preferred toolkit is AppSDK2, specifically the SnapshotStore.
For Javascript apps, the Lumenize javascript library is separate from LBAPI, but was developed by Rally's director of analytics and is bundled in the SDK. You can find some examples of using LBAPI and Lumenize to produce charting as part of some Rally-internal and Rally-customer Hackathon projects here:
https://github.com/RallyHackathon
Please be cautious with these examples for a couple of reasons:
Several aspects of the Lumenize namespace will be changing/renamed for clarity
There's a bug in the current version of Lumenize where its timeSeriesCalculator does not correctly account for stories deleted or reparented.
Hopefully there will be an updated version of AppSDK2 bundled and released soon to consolidate the Lumenize namespace and resolve the bug, so that there's better glue between AppSDK2 and LBAPI for Javascript App development.
Unfortunately, the .NET, Java and Python toolkits have not yet been updated to support the Lookback API. As a result, you'll have to do an HTTP POST to the Lookback API's REST endpoint directly, with a body similar to the one Mark W listed above and Content-Type 'application/json'.
I'd recommend using the Chrome extension 'XHR Poster' to experiment with what you're sending from a browser:
https://chrome.google.com/webstore/detail/xhr-poster/akdbimilobjkfhgamdhneckaifceicen