Too Many Child context Mule 4 - mule

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.

Related

REST bulk endpoint for fetching data

We(producer for the API) have an endpoint
/users/:{id}/name
which is used to retrieve name for the user 'id'
Now as a consumer I want to display the list of names for users like:
user1: id1, name1
uder2: id2, name2
where I have the ids in input.
In such a case should I make 2(here the list is dependent on UI pagination example 50) separate calls to the API to fetch information or else create/ask the producer to create a bulk endpoint like:
POST /users/name
body: { ids: []}
If later, then am I not loosing the REST principle here to fetch information using POST but not GET? If former, then I am not putting too much network overhead in the system?
Also since this seems to be a very common usecase, if we choose the POST method is there really a need of the GET endpoint since the POST endpoint can handle a single user as well?
Which approach should be chosen?
A GET API call should be used for fetching data. Since browser knows GET calls are idempotent, it can handle some situations on its own, like make another call if previous fails.
Since REST calls are lightweight, we tend to overuse API call repeatedly. In your case, since you want all name v/s id mapping at once, one call is sufficient. Or have a Aggregator endpoint in backend API gateway to reduce network traffic and make repeated calls nearer to actual service.
Keeping GET /users/:{id}/name , is also not a bad idea alongside this. It helps to abstract business functionality. A particular scenario can only allow single fetch.
Also using GET /users/name with pagination and returning list of names is complex for single use so keeping both are fine.

How to hit an API parallely with different input paramters

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.

crawl requestes in FIFO order with scrapy

i want scrapy to process the crawl in FIFO order, for example i have a loop in that loop each element process 3 DEPTH nodes, the second element start after completed the first one with 3 DEPTH calls.
The way I would solve this is to put all the data that is needed to make a request in meta and have a parsing function that would handle 2 cases.
First case would handle "3 levels deep and the logic" and things related to that and the second case would be parsing the the main page.
After You have done that simply return a request to call the same function again.
General idea is to have all the "next step" information in meta and act on that information to separate the cases.

mvc4 passing data between paging action and views

i have an action which will invoke a service (not database)to get some data for display,and i want to do paging on these data.however,every time a second page is clicked,it will invoke this action and of course invoke the service again,actually when i click the first page link,it already generate the whole data including what the second page needs. i just want to invoke the service once and get all the data,and later when paging,i don't need to invoke the service again,how can i deal with that?hope someone could give me a hint~
There are several ways to address this. If it's practical and a limited amount of data, it's ok to return the entire data set in the first request.
If that's your case I would consider returning a pure JSON object when you load the page initially. You can then deserialize this into a JS object variable on the web page that you can perform your paging operations against. This is an example of client side paging where all the data exists client side.
Another approach is to do Ajax based paging where you request the data for the next page as needed. I would still recommend returning JSON in this scenario as well.
The two approaches differ in that the first one returns all the data upfront, whereas the second one only returns what you need to render any given page.

Silverlight - Making asynchronous calls in a particular order - CRM

I am currently using silverlight to build a control for a CRM form.
There are quite a few asynchronous calls being made where I am retrieving various sets
of data. The problem I am facing however is sometimes the calls are made in a random order
and I need to retrieve the data in a particular order for data binding reasons.
Any idea?
Basically I have 3 Methods -
Retrieve Accounts
Retrieve Opporunities
Retrieve Leads
Each have call backs but I want each to respond with results from callback before moving to the next.
Make the calls synchronous, or
in each call back, invoke the next call