Hi Wilson,

From our observation, we found that after submitting the Web Service request,

if the CCXML script does not send a <avaya.response> back within 1 minute, the mentioned error will occur.


<send name="'avaya.launchresponse'" targettype="'avaya_platform'" target="'avaya.launchresponse'" namelist="status" />

Would you be able to simulate this in your lab environment?


Thanks!

Jack

Hi Wilson,

I have loaded the new AAEP AppIntfWS into the Outbound application.
But when I call the CCXML application it still returns the following error 1 minute after it is started:
Exception: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId.</



Note that, from CCXML browser logs and VXML logs, I can see that the application is still running in the background eventhough the error was thrown

Could you please help to shed some lights on this?



Thanks!

Jack

Hi Wilson,

I'm thinking if we should load the WebService files from EPM every time we develop a new CCXML application?

As we are currently using an older version of Outbound CCXML application which was built during the VP 5.0 era


Thanks

Jack

Hi Wilson,


We have checked, both CCXML and VXML URL have been configured in the Application.
However, the problem still persists.

Do you have any suggestion on how to further troubleshoot the issue?


Thanks!

Jack

Hi Wilson,

Great point, may I know if it is necessary to set both CCXML and VXML URL in Experience Portal's Application page?

I need to double check our configuration, as I remember we only configured CCXML link only.


Thanks

Jack

Hi Wilson,

Hope you are well.

I have uploaded our application logs and CCXML file for you to study.


The call start time is 2020-07-02 17:54:50, and our application captured the following error returned from the VPMS Web Service:

<Reason>Exception: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId.</Reason>
<LocalizedMsg>detail: ; nested exception is:
org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId.</LocalizedMsg>
<msg>detail: ; nested exception is:
org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId.</msg>
<stacktrace>detail: [Ljava.lang.StackTraceElement;@4293f41e</stacktrace>
<FaultCode>{http://schemas.xmlsoap.org/soap/envelope/}Server.generalException</FaultCode>
<FaultDetails>[Lorg.w3c.dom.Element;@70fd3887</FaultDetails>
<FaultDescription>null</FaultDescription>



Thanks

Jack

Hi Guys,

I am experiencing a problem with a Outbound application, which is developed based on the "ClickToCall" sample.
The problem is that, once the following command is launched, after 1 minute it will return with errors
Exception: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId.

The CCXML and Dialog call flow is still running in the background and the call is still connected.
We have already specified the timeout value to be "120", but it seems ineffective.
request.setLaunchTimeout(120);


Much appreciated if somebody could shed some lights on this


Many thanks

Jack

Hi,


We are experiencing issue with EMC where the EMC Desktop could not get the Agent ID. The resolution was to restart the XML server, but the problem reoccur after less than 1 day.
On the other hand, we also have a backup EMC server, where the same problem also occurs, but it took around 20 days before the problem reoccurring.

The bottom right of the EMC Desktop screen would show Agent ID as "Not Set".

From AES TSAPI logs we found the following difference:

Successful scenario:

01/30/2019 14:30:18.683:TSAPI:Thread 0x9b3ddb90: Private Data:
01/30/2019 14:30:18.683:TSAPI:Thread 0x9b3ddb90: value ATTQueryDeviceInfoConfEvent ::=
01/30/2019 14:30:18.683:TSAPI:Thread 0x9b3ddb90: {
01/30/2019 14:30:18.683:TSAPI:Thread 0x9b3ddb90: extensionClass ecProprietary,
01/30/2019 14:30:18.683:TSAPI:Thread 0x9b3ddb90: associatedClass ecLogicalAgent,
01/30/2019 14:30:18.683:TSAPI:Thread 0x9b3ddb90: associatedDevice "4745"
01/30/2019 14:30:18.683:TSAPI:Thread 0x9b3ddb90: }




Unsuccessful scenario:

01/30/2019 14:31:11.335:TSAPI:Thread 0x9b3ddb90: Private Data:
01/30/2019 14:31:11.335:TSAPI:Thread 0x9b3ddb90: value ATTQueryDeviceInfoConfEvent ::=
01/30/2019 14:31:11.335:TSAPI:Thread 0x9b3ddb90: {
01/30/2019 14:31:11.335:TSAPI:Thread 0x9b3ddb90: extensionClass ecProprietary,
01/30/2019 14:31:11.336:TSAPI:Thread 0x9b3ddb90: associatedClass ecOther,
01/30/2019 14:31:11.336:TSAPI:Thread 0x9b3ddb90: associatedDevice ""
01/30/2019 14:31:11.336:TSAPI:Thread 0x9b3ddb90: }



The problem seems to suddenly occur after the system have been running for over 2 years and no configuration have been changed.

Would be really grateful if anybody could share some ideas on this case.

Jack

Hi Wilson,

Hope all is well.

We found that the problem may be located on the XML server of the EMC service.
After we restarted the service, Agent ID information were able to propagate in the TSAPI trace log.

The "ecLogicalAgent" field actually shows agent ID.
Whereas in failed situation the value "ecOther" is returned

The current workaround is to restart the "XML Server" service everyday.

We also have another server running EMC as a backup, and found that the issue occurs around after 20 days of operation.

Do you have any experience or idea on this?




Many thanks!

Hi Wilson,

Yes, you are correct. The UUI value is assigned by our custom made EMC application.

There are actually 2 areas where the UUI value will be assigned.
The first step is from IVR (AAEP).
The second step is from EMC desktop to IVR (AAEP).

Now, the UUI 4581 and 4580 is assigned by IVR. Whereas 47xx is assigned by EMC application.
Our assumption, is that the EMC application did not replace the previous UUI value, hence 4581 and 4580 is still carried back to IVR.

We wonder if this could be a timing issue, where the EMC application initiated the Call Transfer command, but did not assign the UUI value fast enough before the transfer is completed.

FYI, the whole solution have been running for many years, until recently (around 1/2 year ago), the problem start to rose, where the UUI value could not be inserted into the UUI field by our custom made EMC application.

We have rebooted the EMC server a few weeks ago, and the problem seems to have some improvements. We wonder if rebooting the AES server could help on this too.

Let me know your thoughts on this, some advice or ideas would be much appreciated!

Hi Wilson,

I have attached some logs for your checking, incident occurred on 21/1 and 27/1.
There are screenshots which highlighted the wrong "Agent ID" captured.


4580 and 4581 are VDN

Where as it suppose to be capturing 4708 or 4744, which are Agent IDs

Hi Wilson,

We have some new update on this case.

We performed the following 2 changes and below is the symptom:

Change 1:
Added 1 second delay in vector before the call is assigned to AAEP


Change 2:
Reboot the EMC server


And we have the following obeservation:
Change 1:
Instead of assigning "Agent ID" to the UUI field, the "VDN" is assigned



Change 2:
After rebooting the server, everything seems to resumed normal. But the problem reported in Change 1 still occurs occasionally.


I can elaborate some more on how the flow works:

Customer dial to Hotline > IVR picks up call > assign VDN1 to UUI and transfer the call to CSR

CSR picks up the call and ask if customer would like to participate in survey > if yes, then assign the CSR Agent ID number to UUI field and transfer the call to VDN1

IVR survey hotline answers the call, and writes the UUI "Agent ID" to database for record keeping

Now, the problem is, occasionally the VDN1 UUI value is captured in Survey hotline. Whereas in normal case, the UUI should be the Agent ID


Many thanks

I see.....

Its very strange, as the systems were running fine for over 2 years, and it is just recently that UUI data are not propagated in AES. Hence we are quite confirm it is not a configuration problem, instead we suspect it could be either of the following:

1. The AES and Web application servers have been running for a long time and may require a reboot
2. The AES and Web application servers are running slow, hence adding a 1 second delay in vector may help to have enough buffer time for the UUI data to be delivered.


Do you think the above points would be valid?

Thanks

Hi Wilson,


We will gather the required logs for study.

At the mean time, have you ever heard of adding a 1 second delay in vector before routing the call to IVR in order for the UUI data to have time to propagate?


Many thanks

Hi,

We have recently encountered a problem where the aesconnector could not retrieve the UUI data, but checking from AES TSAPI trace logs, the UUI was actually propagated for the corresponding call.

This behavior occurs much frequently over the past few months, whereas previously it only occurs a few times.

We have also restarted Tomcat, but problem still persists. Any help will be very grateful!


EP version: 7.0.1
AES version: 6.3.3 SP3




Many thanks