It would be really convenient to add input mapping for some more properties of the Call REST Service task.
Currently only the OAuth Token is mapped.

This way I can use workflow properties to modify the settings.

For instance:
- Connect Timeout
- Socket Timeout
- User name
- Password

And if possible, add:
- Request method
When I am able to map the Request method as well, I would be able to re-use a generic sub-workflow which would be able to handle all kinds of REST calls. All the payload handling and error handling surrounding a REST call, would be handled by a single workflow.

Ok, thanks for the update.

Timeout Boundary Events are triggered incorrectly in Sub workflows (created using Create Process).

To be able to reproduce this issue, I have created 3 Test Flows (acttached):

TestMainProcess.xml
The Main Workflow which calls a single Sub workflow using Create Process.
In this demo a single TestSubProcess is launched, but in our project setup, multiple Sub Processes are launched. We designed our workflows this way, as was previously suggested by Avaya.

TestSubProcess.xml
The sub workflow creates additional smaller sub workflows using Create Process, in this demo this launches multiple sub processes called TestEmpty.

TestEmpty.xml
This workflow contains just a start+end event, to demonstrate the issue. In our current project workflow, this would contain a REST API call, or Database lookup and several logmessages, result mapping to vars etc.

All Create Process steps use TimeOut Boundary Events to handle lockup and timeouts of the workflows.

Error 1: Invalid triggering of Timeout Boundary Event
When instantiating the TestMainProcess, which creates the TestSubProcess, the First Create Process TestEmpty, always triggers a Timeout Boundary Event. This can be reproduced 100% on Breeze Engagement Designer 3.4.0.0.06340003.

NB: In our project workflow, the Timeout handling would trigger separate error handling and logging. The log message is just to demonstrate the issue.

NB: I added some extra LogMessage + Timeout Boundary Events at the start of TestSubProcess, to test if the error is related to the first Timeout Boundary Event or the first Create Process. It is related to Create Process.

Remark:
When launching TestSubProcess directly (so not using TestMainProcess), the issue does not occur.
But this is not a solution for us, as using a single large workflow would make it way too big and complex and introduces Editing timeouts and Save bugs in Engagement Designer.
So we really require the 2 subprocess levels.

Error 2:
Sometimes TestSubProcess remains Active because a random Create process TestEmpty + attached Timeout Boundary Event remain active (even when the TestEmpty workflow is finished).
I cannot reproduce this easily, but it occurs once in a while.

I did more testing in Breeze 3.4 related to Create Process and Timeout Boundary Events.

There is still an issue where a Timeout Boundary Event is launched incorrectly.

I will create a new topic and add some example workflows.

Great, Thanks!

I can confirm the problem is fixed in ED 3.4.

Note that the Rest API task no longer supports a Timeout Boundary Event, but 2 extra timeout properties were added in 3.4.

Request:
It would be great to have an input mapping of these 2 timeout properties, so I am able to configure the timeout properties using mapped workflow properties.

OK, thanks for the update.

I guess I have to wait till Dec 18, as I am not able to find ED on PLDS at the moment, only Breeze 3.4. But that's ok.

I noticed Breeze 3.4 is released.

But according to the Breeze 3.4 compatibility matrix, ED 3.3 does not work on Breeze 3.4.

So any ETA on ED 3.4?

NB: Currently running ED 3.3.0.0.25079 on Breeze 3.3.1.1 fixes the timeout issue, but I would like to use a GA version when it becomes available.

Ok thanks! Holding my breath... :wink:

My main workflow uses CreateProcess which runs a seperate workflow with a REST Api call.
The REST Api task has an Error event and Timeout boundary event attached.

In ED 3.3 25042 this works fine.

Just upgraded to ED 33SP1 (25057) and now this flow, which previously worked in 25042, is no longer working.

In ED 25057 the Timeout Boundary Event, attached to the Rest Api Call, remains yellow (active).
The flow remains active in Admin Console and does not Complete, although the End Event is reached (all green blocks, including Rest Api block).
The main flow remains Active as well, as the CreateProcess step remains yellow (active) as well.

I noticed a remark about an issue with Timeout Boundary Event in the ED release notes.
Problem: Timeout Boundary event - TBE is not working
Workaround:
Reference:
WORKFLOW- 6153
Keywords: Timeout Boundary event

Is my problem perhaps related to this known problem? Will a patch be available (soon!)? 8)

See attachment for details of the REST API block.

Ok thanks.

I will add the SuspendCall step at the beginning of the workflow.

Consider the following ED workflow:

Start Call intercept -> do a lot of "Call REST Service" and "Read from DB" -> Call Allow / Drop / Transfer

Is it mandatory to use the SuspendCall step as the first step in my Call Intercept workflow when starting the flow?

Perhaps related: In the Avaya Breeze Snap-in Development Guide, Chapter 6 "Performance and scalability considerations", the call.suspend step is also mentioned to enhance performance:
- Important: Be sure to invoke the suspend method as shown above (call.suspend() ) before invoking the asynchronous method.