MNI on integration taking more time

Appian process execution is made to scale in number of simultaneous active processes, not in lowest execution time for a single node. MNI in parallel does not ultimately mean that each node instance runs at the exact same time.

Is that an issue in any way?

Also see community.appian.com/.../lag-using-call-integration-smart-service

Hi Stefan,

I was under the assumption that if i run 10 requests in parallel using MNI then it would take less time than the sequential call. For example, if sequential approach take 10 seconds overall to complete the 10 requests processing then the parallel would take around 5 seconds or less to complete all the 10 parallel calls. We have a requirement where we need to make parallel calls for N number of requests to load data for user interaction. Right now, 10 calls is taking more 15 seconds to load data on the page and when I see the MNI integration, its taking most of the time taken for completion of execution.

If this is just about loading data, why doing MNI? Can't you do that in an expression?

Firstly, I'd challenge the design. Performance is greatly affected when making calls across the network. It would be better to make a single call to the API endpoint with your array of data and have it locally process that array. If it can't do that today then it's worth discussing with the API provider to see if they can make a change to support that.

Secondly, whilst Appian can make multiple concurrent calls in the way you describe there's no guarantee that the end point can handle the concurrency that you're inflicting upon it. It may queue your requests and so your desire for parallelism may be thwarted anyway and reduced to serialization. Again, a discussion with the API provider might open up some avenues for improvement.

Sorry for the delay in response. It is not about loading the data. I make a search call which returns 50 parties and for each party I need to make a read call to get the relationship that party has with other parties. So if I call the read party 50 times in sequences then its taking too much time. I thought parallel call would reduce the time since threads execute in parallel but after implementing, I saw the completion time of each thread increasing in sequential manner even though the start time was the same for all the calls.

Hi Stewart,

We did discuss it with the API provider but they refused to build the API to handle array input (to handle this parallel processing at their end) stating it would timeout (I know its weird but they are not ready to implement it). I saw the start time of all the thread in Appian were same and I also verified the target system start/end time for each of these calls. The start time was almost the same for all threads at their end with some milli seconds difference for few threads and the end time also were almost the same. Appian took more time to complete the integration configured as MNI.

MNI in a process is in no way comparable to multithreading in e.g. Java. Process models in Appian are made to express a business process, not to implement high performance technical algorithms.

In Appian expressions, a forEach will try to execute iterations in parallel. docs.appian.com/.../Expressions.html

Again I think there might be value in rethinking this. If I understand correctly, you're making a call to get 50 Party entities based upon some search criteria; and, for each, you want to return up to 50 related Party entities.

There are two possible scenarios that may be in play here (I'm going to elaborate both because I don't see anywhere in this thread what the actual context is):

1. the calls are unattended. That is, there is no user waiting for the response to the retrieval of this data. If that's the case then it's highly likely that the response time isn't an issue. If it takes several minutes, what would be the impact? Would it matter?
2. I'm guess (from the fact that you're trying to resolve the response time) that there is a User waiting for the data to be retrieved, in which case response time is something you want to manage. BUT: also consider the UX here. If I conduct a search which returns 50 Party entitles, do I (as a User) want to see all 50 child Party entities for every parent Party entity? That would be way too much data on one User Interface for me to even digest. Would it not be a better UX to retrieve the initial list of 50, present sufficient information to help me zoom in on the one Party I do want to look at/investigate and then navigate into that Party, at which point I can then make a second call on-demand to retrieve the 50 child Party entities. So now your performance/response time is affected only by the scope of the attributes being retrieved for 50 rows at any one time

Hi Stewart,

As you said, we could have 50 relationships for each of the 50 parties. After the MNI integration call, I have a script task where I use the response of the 50 parallel calls and construct my array CDT to show in the UI. Let me elaborate the use case. User enters name of a party and that name could end up with around 50 or more parties (there is a possibility of multiple parties having same name and user wants the option to see all these parties info as that is the requirement. So once the user enters the name we make a search call which could return 50 parties at the max in response. Now for these 50 parties, I need to fetch the relationship details (each party could have n number of relationships). Each read call here would return single or multiple relationship which is working fine for me right now. The problem is with the Integration call that I am making for read API using MNI. I did check the logs of the target system and the start time for all the 50 read calls is almost the same and the response of each of those is also almost same with some microseconds difference. For example, if request 1 to 50 reached target at 11:31:05:000 AM, the response sent for each of these 50 calls by the target system is 11:31:05:180 AM - 11:31:05:235 AM time range. All the responses were sent back within a second. The MNI is taking more time to consolidate the overall response. In the output of the MNI, I am appending the Result in a pv and not performing any other activity there. I even tested by removing the append from the output just to see the time consumed by the MNI which still showed the same delay. For testing, I limited the response of the first search call to 10 and for 10 read calls in MNI, I am facing this issue. For 50, its ending up with unattended issue. For 10 calls, I am getting the data and UI is also loading with proper data but the time taken for MNI to complete is more than 10 seconds. Sometimes, it ends up taking 30+ seconds to load the UI.

The target system is not ready to implement the orchestration at their end even though they are supposed to. I posted the query here to understand why Appian MNI is taking so much time when the target system is giving the response for all the threads within a second.