Thank you both for your support,

I've finally figured it out. Basically, I am using ED to invoke a call flow via a HTTP request. Then, I am doing a single party make call with the flag to wait until called picks up, then writing an event to a custom family I created. Next, I add a participant to the call followed by a Receive step which waits for the participant to connect. That is then followed by another writing of an event stating the participant joined. Toward the tail end of the work flow there is another Receive step checking for the call family event on whether or not a CALL_ENDED occurred. If it did, a final Event is sent via my custom Event family. All in all, I now have a working solution.

My biggest struggle was that I thought i could add a message boundary to the "Make Call" step (two party call) as that would make the whole call flow much simpler. This did not work though because the workflow is triggered by a HTTP request and not an inbound call where the UCID is not known until the Make Call step completes and I can read its output.

Alex

Thank you @dineshud.avaya.com

Can you be more specific around publishing of the event? I do not see a reference to it under the REST capabilities of the Eventing Framework Connector.

So far, I have working

1. Subscribe to the event (I can see the response come back accordingly on my web server)
2. Trigger the event I have mapped to a workflow in Engagement Designer

Unfortunately, I do not see any callbacks aside from the subscription and I suppose it is because I cannot yet figure out the publish step. What REST call would achieve a publishing of the event?

Many thanks,
Alex

Thanks for your reply John,

I've looked at these and understand that eventing is possible but I fail to grasp how this can be done by purely doing REST calls to Breeze versus writing an application to do so. Ideally, what I am after is to simply do a REST POST to Breeze by providing a correlationId which I would include in the initial REST POST to trigger the event and receive a response from Breeze. Or maybe, provide Breeze a callback URL via a REST POST where Breeze can send events. Is what I am after possible and if so, can you elude to the specifics?

Cheers,
Alex

P.S. - would i be on the right path by looking at EFC REST services? ... something like posting to breeze as below to get callbacks from Breeze on status based on family and filter spec?

<Breeze security module address>/services/EventingConnector/subscriptions
{
"family" :"MyFamily",
"callbackUrl":"http(s)://ip/EventListener"
}

Hi,

Can anyone suggest how I can get status (at any point in time during the workflow being active) of a workflow that has been triggered using a REST call to Breeze (https://<breeze_secmodule_ip>/services/EventingConnector/events including appropriate payload)? As far as I can tell with my testing/attempts thus far, Breeze does not return anything except for a 200 OK when I invoke the REST call to it. The workflow itself functions as expected.

Many thanks

Alex

Thanks for your reply PhamTuan,

i understand that CM only sends the reason code (integer value) to one-x agent. But, I would expect one-x Agent to properly identify the reason code as I have the proper mapping of reason codes to reason code names within one-x agent configuration (see below sample config)


Knowing the above, are you saying so long as the mapping is there and properly lines up, we should expect one-x Agent to properly show the reason code name? If so then I think this is a bug with One-x agent. Looking forward to your guys reply.

Alex

auxReasonCodes.xml for my one-x Agent setup (noting the mapping I have configured correctly)

<?xml version="1.0"?>

<ReasonCodes xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" Id="0" IsLeaf="false" ReadOnly="false" DefaultGuid="a47969b6-33b2-44c3-82d1-b972379568c3" Version="2.5.60313.0" xmlns="http://avaya.com/OneXAgent/ObjectModel/ReasonCode">

  <ReasonCodes Id="0" Label="default" IsLeaf="true" ReadOnly="false" Guid="a47969b6-33b2-44c3-82d1-b972379568c3" />

  <ReasonCodes Id="1" Label="Project Work" IsLeaf="true" ReadOnly="false" Guid="a233d786-8d59-4a69-85c4-ba91378a8c36" />

  <ReasonCodes Id="2" Label="Team Meeting" IsLeaf="true" ReadOnly="false" Guid="b4f832b8-82fc-462e-a776-1b2c49235a65" />

  <ReasonCodes Id="3" Label="Training" IsLeaf="true" ReadOnly="false" Guid="7476debe-7c40-4652-8610-a6934de9760a" />

  <ReasonCodes Id="4" Label="Break" IsLeaf="true" ReadOnly="false" Guid="e943dd05-d5aa-413a-995b-2a97c85940de" />

  <ReasonCodes Id="5" Label="Lunch" IsLeaf="true" ReadOnly="false" Guid="f86ffb2f-d739-407e-95ae-215fedfbd2fe" />

  <ReasonCodes Id="6" Label="Case Work" IsLeaf="true" ReadOnly="false" Guid="1656c3f0-d73b-4a33-9753-0696840167f4" />

  <ReasonCodes Id="7" Label="DM Activities" IsLeaf="true" ReadOnly="false" Guid="30e00be1-4ec9-4066-8dcf-c06743844621" />

  <ReasonCodes Id="8" Label="Expert Case Work" IsLeaf="true" ReadOnly="false" Guid="2a88302f-2a2c-4f6b-b1ea-89d402f0102c" />

  <ReasonCodes Id="9" Label="Email/Chat Case Work" IsLeaf="true" ReadOnly="false" Guid="2282b157-79d9-4c78-afc4-3ddc6ede5492" />

</ReasonCodes>

Martin,

Thanks for your reply but something doesn't make sense to me.

In the logs of Avaya One-X Agent, I can clearly see that CM pushed the aux work mode state and reason code (4 in the log excert case I provided earlier). So, based on that, we can see CM letting one-x Agent know about both aux work plus reason code. Are you suggesting this is a limitation of the One-X Agent client itself only? And, if so - are you aware whether there any JIRA etc items open for that product team to look into this scenario?

Please note that I was asked to post on Devconnect after opening up an SR and being told that this is a devconnect item since SDK's are involved.

Many thanks,
Alex

Hello,

While using the Avaya DMCC sample application, I found that the aux work reason code does not propagate to the Avaya one-X Agent clientyet:

The reason code is properly reflected on CM

The reason code is seen in the Avaya one-X Agent log as delivered to one-X agent client

The Avaya one-X Agent client goes into aux work hence not allowed to take ACD queue calls

Is there a known issue with Avaya one-X Agent not displaying the reason code of the aux work state change? Note that the one-x agent client does change to aux work (just fails to show the reason code).

Some more details info below


One-X Agent build: 2.5.20020.0 (Spark version: 2.5.51.3) and latest GA build 2.5.60313.0 (Spark version: 2.5.13.0)


The reason codes are properly assigned within Avaya one-X Agent settings.


Changing to aux work and desired reason code on the Avaya one-x Agent itself displays the reason code correctly

Log excerpt at the exact time when auxwork 4 is requested:

2019-06-17 15:45:41,919 DEBUG 19984 Avaya.OneXAgent.ModelManager.WorkModelManager SessionImpl[S1:0a7ea272-08ce-4ba3-a0da-7625d6c80e0a].StateImpl=[duration=0,operations=[login=False,logout=True,shutdown=False,enterAux=True,enterReady=False,addWorkItem=True,addVoiceInteraction=True,loginAgent=False,loginIM=True,desktopSharing=True,video=True,tty=True,logoutAgent=True,enterFollowUp=False,observe=False,unobserve=False,remoteAgentLogout=False,quickAlert=False,],type=Ready,]

2019-06-17 15:46:28,389 DEBUG 13224 Avaya.OneXAgent.CMService.Commands.Dispatcher Dispatcher: Received Event - ASTFeaturesListEvent

2019-06-17 15:46:28,389 DEBUG 13224 Avaya.OneXAgent.CMService.Commands.IncomingHandlerCommand IncomingCommandHandler: Received event - ASTFeaturesListEvent

2019-06-17 15:46:28,389 INFO 13224 Avaya.OneXAgent.CMService.Commands.IncomingHandlerCommand manual-in Button transitioned from on to off

2019-06-17 15:46:28,389 DEBUG 13224 Avaya.OneXAgent.CMService.Commands.IncomingHandlerCommand Feature : Manual In

2019-06-17 15:46:28,389 DEBUG 13224 Avaya.OneXAgent.CMService.Commands.IncomingHandlerCommand Attr Name = avaya-cm-action, Value = on

2019-06-17 15:46:28,389 INFO 16936 Avaya.OneXAgent.WorkService.WorkServiceImpl PhoneService_AgentStateChanged:oldState=Ready;newState=LoggedOut

2019-06-17 15:46:28,389 INFO 16936 Avaya.OneXAgent.WorkService.WorkServiceImpl UpdateSessionState: Agent State LoggedOut

2019-06-17 15:46:28,389 DEBUG 13224 Avaya.OneXAgent.CMService.Commands.Dispatcher Dispatcher: Received Event - ASTFeaturesListEvent

2019-06-17 15:46:28,389 DEBUG 13224 Avaya.OneXAgent.CMService.Commands.IncomingHandlerCommand IncomingCommandHandler: Received event - ASTFeaturesListEvent

2019-06-17 15:46:28,389 INFO 13224 Avaya.OneXAgent.CMService.Commands.IncomingHandlerCommand aux-work Button transitioned from off to on

2019-06-17 15:46:28,389 DEBUG 13224 Avaya.OneXAgent.CMService.Commands.IncomingHandlerCommand Feature : AuxWork 4

2019-06-17 15:46:28,389 DEBUG 13224 Avaya.OneXAgent.CMService.Commands.IncomingHandlerCommand Attr Name = avaya-cm-action, Value = on

2019-06-17 15:46:28,390 DEBUG 19984 Avaya.OneXAgent.Work.SessionStateImpl Object is detached from model:SessionStateImpl[Ready]

2019-06-17 15:46:28,391 DEBUG 19984 Avaya.OneXAgent.ModelManager.WorkModelManager SessionImpl[S1:0a7ea272-08ce-4ba3-a0da-7625d6c80e0a].StateImpl=[duration=0,operations=[login=False,logout=True,shutdown=False,enterAux=False,enterReady=False,addWorkItem=True,addVoiceInteraction=True,loginAgent=True,loginIM=True,desktopSharing=True,video=True,tty=True,logoutAgent=False,enterFollowUp=False,observe=False,unobserve=False,remoteAgentLogout=False,quickAlert=False,],type=LoggedIn,]

2019-06-17 15:46:28,391 INFO 16936 Avaya.OneXAgent.WorkService.WorkServiceImpl PhoneService_AgentStateChanged:oldState=LoggedOut;newState=Aux

2019-06-17 15:46:28,391 INFO 16936 Avaya.OneXAgent.WorkService.WorkServiceImpl UpdateSessionState: Agent State Aux

2019-06-17 15:46:28,392 DEBUG 19984 Avaya.OneXAgent.Work.SessionStateImpl Object is detached from model:SessionStateImpl[LoggedIn]

2019-06-17 15:46:28,393 DEBUG 19984 Avaya.OneXAgent.ModelManager.WorkModelManager SessionImpl[S1:0a7ea272-08ce-4ba3-a0da-7625d6c80e0a].StateImpl=[duration=0,operations=[login=False,logout=True,shutdown=False,enterAux=True,enterReady=True,addWorkItem=True,addVoiceInteraction=True,loginAgent=False,loginIM=True,desktopSharing=True,video=True,tty=True,logoutAgent=True,enterFollowUp=False,observe=False,unobserve=False,remoteAgentLogout=False,quickAlert=False,],type=Aux,]

John,

Thanks very much for the prompt reply!

In the event where I am trying to accomplish the following call flow, how could I get the ring back to happen?

1. ACE invokes make call and adds participant A (no problem here)
2. ACE adds vxml as a participant (no problem here)
3. Participant A listens to vxml and presses a digit to confirm it (no problem here)
4. vxml does a data src call to a URL which triggers a wsdl for ACE to add another participant
5. ACE adds participant B (this is where participant A does not hear the ringback)
6. Participant B eventually picks up
7. Both participant A and B are on the call and can hear one another

NOTE
I also tried to modify 4 where the vxml itself would invoke a <transfer> but could only get it to work as a blind transfer (not bridged). As a blind transfer direct from vxml without doing a call back to ACE to addparticipant, no ringback is heard either.

I do understand your point about ACE treating the call as a conference so maybe I am approaching my call flow goals the wrong way? As a side note, we are in process of getting quotes for Breeze with our Avaya rep but having to solve this on ACE for the time being is ideal.

I also found the below forum post in the Breeze section which may shed some light?
https://www.devconnectprogram.com/forums/posts/list/21681.page#p152119

Again, thanks very much for your support!
Alex

Hi,

Can anyone provide feedback on why I am not hearing ring back on the first participant that is joined into a call using ACE third party call control v3.4 after joining a second participant in?

The particulars (please ignore the markup of quotes etc. as this was a direct copy from my programming language invoking a server side get):

1. ACE web call invoked to make call and join the first participant

	"<soapenv:Envelope xmlns:soapenv=""http://schemas.xmlsoap.org/soap/envelope/"" xmlns:loc=""http://www.csapi.org/schema/parlayx/third_party_call/v3_4/local"">"&_

	 "<soapenv:Body>"&_

		"<loc:makeCallSession>" &_

			"<loc:callParticipants>5554848@mydomain.com</loc:callParticipants>" &_

		"</loc:makeCallSession>" &_

	 "</soapenv:Body>"&_

	"</soapenv:Envelope>"

2. ACE web call invoked to join the second participant (after the first picks up). This is where I would expect the first participant to hear ringing while the second participant is called out to join the call.

	"<soapenv:Envelope xmlns:soapenv=""http://schemas.xmlsoap.org/soap/envelope/"" xmlns:loc=""http://www.csapi.org/schema/parlayx/third_party_call/v3_4/local"">"&_

	 "<soapenv:Body>"&_

		"<loc:addCallParticipant>" &_

			"<loc:callSessionIdentifier>34983498-askjfs3498-ThisiscallSessionID-43898</loc:callSessionIdentifier>"&_

			"<loc:callParticipant>984398@mydomain.com</loc:callParticipant>" &_

		"</loc:addCallParticipant>" &_

	 "</soapenv:Body>"&_

	"</soapenv:Envelope>"

I do have AMS in the picture with configuration for ANNC etc which I presume is correct because my other call flows that leverage vxml and DTMF injection work without issue.

Many thanks
Alex