Our Customer is using the POM 3.1.2 with PostgreSQL 9.6.16.
In this case, PostgreSQL 9.6.16 is going to move it to EoL on November 11, 2021.
After reached EoL, can Avaya still support the PostgreSQL 9.6.16 for POM 3.1.2?

Of cause Customer is going to upgrade DB to ver 10 or 13(Latest) in near future.
And until done it, Avaya or BPE/Customer found any DB related issue, BPE will upgrade DB as soon as possibe.
In this case, How do they consider the compatibilities between POM version and DB(PostgreSQL) version?

If AVAYA has any compatibilities information between POM version and all of supported DB(Oracle, Microsoft SQL server databases) version, please advise for us for future plan as well ?

https://www.postgresql.org/support/versioning/
Releases
Version Current_minor Supported FirstRelease FinalRelease
13 13.2 Yes September 24, 2020 November 13, 2025
12 12.6 Yes October 3, 2019 November 14, 2024
11 11.11 Yes October 18, 2018 November 9, 2023
10 10.16 Yes October 5, 2017 November 10, 2022
9.6 9.6.21 Yes September 29, 2016 November 11, 2021
9.5 9.5.25 No January 7, 2016 February 11, 2021

Best regards, K.Yamahara

Hi Wilson-san,

Thank you for your reply.
I'm co-working with Yoshihiko-san.

We understood that the OD applications and AES Connector app have to be on the same server instance.
On the other hands, we have one more idea of configuration as below.

The OD applications and AES Connector app are on the same server instance.
And the Multiple server instance(Instance A and Instance B) on the same Websphere application server.
In this configuration, can the OD applications and AES Connector app will be work well?

Best regards, K.Yamahara

Hi Wilson-san,

Thank you for your helpful reply.

I understood your information.
We will try to do working-around once.

Thank you and regards, K.Yamahara

Hi Wilson-san,

Thank you for your reply.
I tried to search the forum for old posts discussing the same thing. As a results, I found below thread.

https://www.devconnectprogram.com/forums/posts/list/2595.page

Is this same thing which you said?

Your additional advise is very appreciate it for me.
Best regards, K.Yamahara

Hi Team,

We are using EP based IVR-AP server with EP ver.6 and OD ver.7.
In this case, CPU usage was increased almost 100%.
In our investigation, OD tried to mkdir for log directory. However log directory already existed.
Then mjdir operation was aborted.
Then lot of below error message was indicated in /audit/trail file.

-----
FS_Mkdir FAIL root
mode: 755 dir:
/usr/atb/web/installedApps/TBCell/TBIVR_AvayaOD_Application.ear/TBIVR.war/data/log
-----

Did your team heard similar phenomenon on other customer sites in the past?
If yes, is it OD related issue?

if you have any idea to resolve this issue, please advice.
At that time, we resolved this issue when we tried to reboot WAS.

Best regards, K.Yamahara

Hi Wilson-san,

Thank you fopr your quick reply.
I understood it. So, we will try to do that.

Thank you, K.Yamahara

Hi Team,

We faced the MPP port can not disconnect issue by standard disconnect(not CTI disconnect from AES) due to changed CTI active state.
-----
@2018-11-01 19:04:07,198||FINE|Tele|26267|FileName=h323/CCMSStation.cpp,LineNumber=2793|CCMSStation::DropCall: 58473 CTI ACTIVE on Endpoint 121|tccspi6f####
-----
Actually, we are working with CM and AES engineer with SR ticket.
However we need more time to fix this issue.

Therefore we are going to add the "CTI Disconnect" request before "Standard Disconnect" like below OD call flow as work around until fix this issue.

But we can not re-produce same issue. So, could you advice how can we forceed change MPP port state to CTI active?
We tried to add "CTI Hold" before "CTI Disconnect" in OD call flow.


My Test Date/Time?2018/11/5 11:53

Expansion?40003
VDN?41026

MPP Port?46702?MPP#1?
SessionID?mpp1-2018309025334-4

=====
05/11/2018 11:53:28:886 DEBUG - CallInfo.doGetCallInfo: Got call info for extension 46702
05/11/2018 11:53:32:152 DEBUG - Hold.doHold:46702 putting on hold ext:46702
05/11/2018 11:53:32:214 DEBUG - CTICallObserver.addApplicationObserver: adding an app observer to extension:46702
05/11/2018 11:53:32:214 DEBUG - Hold.doHold 46702: Placing terminal connection 0 on hold...
05/11/2018 11:53:32:214 DEBUG - Hold.doHold 46702: Waiting....
05/11/2018 11:53:32:277 DEBUG - CTICallObserver.callChangedEvent: Number of events on extension 46702 is 1
05/11/2018 11:53:32:277 DEBUG - CTICallObserver.callChangedEvent 46702: Event: 0 is 216 for call 78 Provider:AES2
05/11/2018 11:53:32:277 DEBUG - CTICallObserver.callChangedEvent:46702: got Terminal Connection Held Event
05/11/2018 11:53:32:277 DEBUG - CTICallObserver.updateCallState 46702: setting call:78 to state:held
05/11/2018 11:53:32:277 DEBUG - CTICallObserver.updateCallState 46702: setting cached call:78 to state:held
05/11/2018 11:53:32:277 DEBUG - CTICallObserver.notifyApplicationObserver: Notifying 46702 about call event
05/11/2018 11:53:32:277 DEBUG - Hold.doHold 46702: Terminal connection 0 placed on hold
05/11/2018 11:53:32:277 DEBUG - Hold.doHold 46702: Done placing connections on hold
05/11/2018 11:53:32:277 DEBUG - CTICallObserver.removeApplicationObserver: removing an app observer from extension:46702
05/11/2018 11:53:35:292 DEBUG - getObserversFromCallId: gathering observers... done waiting on sync list size of list is 1
05/11/2018 11:53:35:292 DEBUG - getObserversFromCallId: done gathering observers
05/11/2018 11:53:35:292 DEBUG - CTIConnectorManager.dropCall: Call state of call 78 is ACTIVE
05/11/2018 11:53:35:292 DEBUG - CTIConnectorManager.dropCall: Connection 0 state is CONNECTED
05/11/2018 11:53:35:292 DEBUG - CTIConnectorManager.dropCall: Connection 0 for address 40003
05/11/2018 11:53:35:292 DEBUG - CTIConnectorManager.dropCall: Connection 1 state is CONNECTED
05/11/2018 11:53:35:292 DEBUG - CTIConnectorManager.dropCall: Connection 1 for address 46702
05/11/2018 11:53:35:292 DEBUG - CTIConnectorManager.dropCall: Disconnecting connection for address 46702...
05/11/2018 11:53:35:292 DEBUG - CTICallObserver.doDisconnect:no UUI during disconnect for cid:com.avaya.sce.cticonnector.servlet.server.CallInfoData@354d2f70
05/11/2018 11:53:35:370 ERROR - CTIConnectorManager.doDisconnect: Unable to drop call: clearConnection failure
05/11/2018 11:53:35:370 DEBUG - CTIConnectorManager.dropCall: Call com.avaya.jtapi.tsapi.impl.LucentV7CallImpl@4599034e dropped
05/11/2018 11:53:35:370 DEBUG - getObserversFromCallId: gathering observers... done waiting on sync list size of list is 1
05/11/2018 11:53:35:386 DEBUG - getObserversFromCallId: done gathering observers
05/11/2018 11:53:35:386 DEBUG - CTICallObserver.updateCallState 46702: setting call:78 to state:disconnected
05/11/2018 11:53:35:386 DEBUG - CTICallObserver.updateCallState 46702: setting cached call:78 to state:disconnected
05/11/2018 11:53:35:386 DEBUG - Ending call on extension 46702
=====

<< Session manager log >>
@2018-11-05 11:53:38,624||FINER|Tele|6228|FileName=h323/CCMSStation.cpp,LineNumber=2086|CCMSStation::LineAppearanceUpdate: 46702 CTI NOW ACTIVE on Endpoint 1|mpp1.ve.avaya.tsuzuki.co.jp####
:
@2018-11-05 11:53:41,670||FINE|Tele|6228|FileName=h323/CCMSStation.cpp,LineNumber=2785|CCMSStation::DropCall: 46702 CTI ACTIVE on Endpoint 1|mpp1.ve.avaya.tsuzuki.co.jp####

Best regards, K.Yamahara

Hi team,

Could any one help on this?

Best regards, K.Yamahara

Hi Team,

I found below similar ticket in Archive of OD forum.

https://www.devconnectprogram.com/forums/posts/list/8899.page
Subject: cti transfer disconnect by 1st caller which exception is thrown?

Then I also found below comment.
Is this also meet for my inquiry?
-----
You can only get the SCERuntimeException at the application level. That's what you get in all cases of CTIC operation failures. To tell whether the 1st caller hangs up, you can handle the connection.disconnect event in the Approot. So you need to use the try/catch to handle the SCERuntimeException to make sure this error does not interrupt the call, and let the connection.disconnect event handler take care of what you need to do.
-----

If yes, please advice what kind of CTIC operation failures could you estimated?

Best regards, K.Yamahara

Hi Team,

As I informed that Call was transfered correctlly.
Therefore I would like to know below point if this is usual message.

1) Please explain the reason why below error log was generated in OD trace.
Is this message generate every cti transfer operation even if the Call was transfered correctly?
-----
20180123 105901430DEBUG2e1XO4wSsVailzOacM1cpVFtb CTICommand.execute setting session cookie to 2e1XO4wSsVailzOacM1cpVFtb
20180123 105901799DEBUG2e1XO4wSsVailzOacM1cpVFtb CTICommand.execute callinfo from Manager is errorMerge.doOperation Unable to perform transfer operation
20180123 105901828ERROR2e1XO4wSsVailzOacM1cpVFtb session idjnntbsymp1-2018023015455-2
EXCEPTION
com.avaya.sce.runtimecommon.SCERuntimeException Merge.doOperation Unable to perform transfer operation
at com.avaya.sce.runtimecommon.SCESession.throwRTException(SCESession.java2554)
at com.avaya.sce.runtime.connectivity.cti.ir.CTICommand.execute(CTICommand.java156)
at com.avaya.sce.runtime.Data.evaluateActions(Data.java228)
at flow.subflow.EventFlow.CallTransfer.executeDataActions(CallTransfer.java95)
at com.avaya.sce.runtime.Data.handleRequest(Data.java121)
at com.avaya.sce.runtime.AppServlet.processRequest(AppServlet.java96)
at com.avaya.sce.runtime.SCEServlet.requestHandler(SCEServlet.java247)
at com.avaya.sce.runtime.SCEServlet.doGet(SCEServlet.java140)
at javax.servlet.http.HttpServlet.service(HttpServlet.java687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java790)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java1290)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java778)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java475)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java1161)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.dispatch(WebAppRequestDispatcher.java1381)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java186)
-----

2) And 6min later, when Generate Manual Forward Event again, No error log was generated in OD trace.
Is this also usual phenomenon?

Best regards, K.Yamahara

Hi Martin-san,

Thank you for your quick reply.

I understood.
I will ask this in forum for Orchestration Designer.

Thank you and regards, K.Yamahara

Hi Team,

We performed AES connector failover test with dual active AES(AES#1 and #2) configuration.

Here are the test scenario.

- At first, AES connector conected AES#2 as active link.
- Call was established from 78121 to VDN 23001
- We disconnected all of AES#2 connected LAN cable from AES connector to occur connction failure.
- The active link was failover from AES#2 to AES#1 with Failover Event(event113).
- When we tried to generate manual transfer event from OD application.
- We confirmed the Call was transfered corectlly.
- However below error log was generated in OD trace.
- 6min later, when Generate Manual Forward Event again, No error log was generated in OD trace.

So, we would like to know the reason why below error log was generated in OD trace.
Because the Application generated the Call Forward Operation error(OE0006) as a results of below error log.
----- generated error log in OD trace -----
20180123 105901799DEBUG2e1XO4wSsVailzOacM1cpVFtb CTICommand.execute callinfo from Manager is errorMerge.doOperation Unable to perform transfer operation
-----

Therefore we tried to perform below test case and pattern.

Operation Pattern
Pattern A AES#2 Failure(Disconnect LAN Cable) occurred, then Generate Manual Forward event before AES connector perfored Failover to AES#1
Pattern B AES#2 Failure(Disconnect LAN Cable) occurred, then Generate Manual Forward event after AES connector perfored Failover to AES#1 immediately
Pattern C AES#2 Failure(Disconnect LAN Cable) occurred, then Generate Manual Forward event 3 min. later after AES connector perfored Failover to AES#1

Test Case

- Test case 1?1st time?Log file :*****_test1
Call established from Ext78121 to VDN23001
Generate Manual Forward Event before failover Message generate Case


10:54:55 Call Generated(78121)
10:56:40 AES#2 Failure(Disconnect LAN Cable) occurred
Generate Manual Forward Event before failover Message generate
10:57:41 Event113 Generated
10:58:21 Event112 Generated
6min later, when Generate Manual Forward Event again, No error log was generated in OD trace.


- Test case 1?2nd time?Log file :*****_test2
Call established from Ext78121 to VDN23001
Generate Manual Forward Event after failover Message generate immediately Case

11:28:08 Call Generated(78121)
11:29:24 AES#2 Failure(Disconnect LAN Cable) occurred
11:30:24 Event113 Generated
11:30:56 Event112 Generated
Generate Manual Forward Event after failover Message generate immediately
6min later, when Generate Manual Forward Event again, No error log was generated in OD trace.

- Test case 2?1st time?Log file :*****_test3
Call established from Ext78123 to VDN23001
Generate Manual Forward Event after failover Message generate immediately Case
Call established from Ext78121 to VDN23001
Generate Manual Forward Event before failover Message generate Case

11:39:41 Call Generated(78123)
11:39:45 Call Generated(78121)
11:42:10 AES#2 Failure(Disconnect LAN Cable) occurred
11:42:30 Generate Manual Forward Event before failover Message generate(78123)
11:43:12 Event113 Generated
11:43:52 Event112 Generated
11:44 Generate Manual Forward Event after failover Message generate immediately(78121)
6min later, when Generate Manual Forward Event again, No error log was generated in OD trace.

- Test case 3?1st time?Log file :*****_test4
Call established from Ext78121 to VDN23001
Generate Manual Forward event 3 min. later after AES connector perfored Failover to AES#1
Call established from Ext78123 to VDN23001
Generate Manual Forward Event before failover Message generate Case

11:53:33 Call Generated(78121)
11:53:36 Call Generated(78123)
11:55:05 AES#2 Failure(Disconnect LAN Cable) occurred
11:55:22 Generate Manual Forward Event before failover Message generate(78123)
11:56:09 Event113 Generated
11:56:49 Event112 Generated
12:00 Generate Manual Forward event 3 min. later after AES connector perfored Failover to AES#1(78121)
6min later, when Generate Manual Forward Event again, No error log was generated in OD trace.

Best regards, K.Yamahara

Hi Martin-san,

Thank you for your quick reply.

I see.
I will open SR ticket.

Before that, I would like like to know below point.
Please advice.

1. Which Logs or information should we provide to SR to investigate this kind of issue?
Actually, we confirmed that the Call was transfered correctly as below logs.
However "Unable to perform transfer operation" error message was generated in OD trace.
And we can not find any related messages(error) in logs which I provided.

Or if you have any information regarding reason why "Unable to perform transfer operation" error message was generated in OD trace, please advice.
-----
23/01/2018 12:00:16:478 DEBUG - Transfer.doMerge:4400042 Updated call info to state:transferred
23/01/2018 12:00:16:478 ERROR - Merge.doOperation: Unable to perform transfer operation
....
23/01/2018 12:00:17:356 DEBUG - CTICallObserver.removeCall:clearing MRCC:2227 from ext:4400042
23/01/2018 12:00:17:356 DEBUG - CTICallObserver.removeCall:removing call:2227 from ext:4400042
23/01/2018 12:00:26:053 DEBUG - ProviderMonitor: Checking:AES#2 for availability
23/01/2018 12:00:26:054 DEBUG - ProviderMonitor:AES#2 is null in our list
-----

2. If it is not issue, and if it is working as design, please also advice.
e.g, We need to wait 5-6 min after Failover. etc,...

Because when we tryied to perform same test 5-6 min later after failover, this error message was NOT generated.

Best regards, K.Yamahara

Hi Team,

We performed AES connector failover test with dual active AES(AES#1 and #2) configuration.

Here are the test scenario.

- At first, AES connector conected AES#2 as active link.
- Call was established from 78121 to VDN 23001
- We disconnected all of AES#2 connected LAN cable from AES connector to occur connction failure.
- The active link was failover from AES#2 to AES#1 with Failover Event(event113).
- When we tried to generate manual transfer event from OD application.
- We confirmed the Call was transfered corectlly.
- However below error log was generated in OD trace.
- 6min later, when Generate Manual Forward Event again, No error log was generated in OD trace.

So, we would like to know the reason why below error log was generated in OD trace.
Because the Application generated the Call Forward Operation error(OE0006) as a results of below error log.
----- generated error log in OD trace -----
20180123 105901799DEBUG2e1XO4wSsVailzOacM1cpVFtb CTICommand.execute callinfo from Manager is errorMerge.doOperation Unable to perform transfer operation
-----

Therefore we tried to perform below test case and pattern.

Operation Pattern
Pattern A AES#2 Failure(Disconnect LAN Cable) occurred, then Generate Manual Forward event before AES connector perfored Failover to AES#1
Pattern B AES#2 Failure(Disconnect LAN Cable) occurred, then Generate Manual Forward event after AES connector perfored Failover to AES#1 immediately
Pattern C AES#2 Failure(Disconnect LAN Cable) occurred, then Generate Manual Forward event 3 min. later after AES connector perfored Failover to AES#1

Test Case

- Test case 1?1st time?Log file :*****_test1
Call established from Ext78121 to VDN23001
Generate Manual Forward Event before failover Message generate Case


10:54:55 Call Generated(78121)
10:56:40 AES#2 Failure(Disconnect LAN Cable) occurred
Generate Manual Forward Event before failover Message generate
10:57:41 Event113 Generated
10:58:21 Event112 Generated
6min later, when Generate Manual Forward Event again, No error log was generated in OD trace.


- Test case 1?2nd time?Log file :*****_test2
Call established from Ext78121 to VDN23001
Generate Manual Forward Event after failover Message generate immediately Case

11:28:08 Call Generated(78121)
11:29:24 AES#2 Failure(Disconnect LAN Cable) occurred
11:30:24 Event113 Generated
11:30:56 Event112 Generated
Generate Manual Forward Event after failover Message generate immediately
6min later, when Generate Manual Forward Event again, No error log was generated in OD trace.

- Test case 2?1st time?Log file :*****_test3
Call established from Ext78123 to VDN23001
Generate Manual Forward Event after failover Message generate immediately Case
Call established from Ext78121 to VDN23001
Generate Manual Forward Event before failover Message generate Case

???11:39:41 Call Generated(78123)
???11:39:45 Call Generated(78121)
???11:42:10 AES#2 Failure(Disconnect LAN Cable) occurred
???11:42:30 Generate Manual Forward Event before failover Message generate(78123)
???11:43:12 Event113 Generated
???11:43:52 Event112 Generated
???11:44 Generate Manual Forward Event after failover Message generate immediately(78121)
6min later, when Generate Manual Forward Event again, No error log was generated in OD trace.

- Test case 3?1st time?Log file :*****_test4
Call established from Ext78121 to VDN23001
Generate Manual Forward event 3 min. later after AES connector perfored Failover to AES#1
Call established from Ext78123 to VDN23001
Generate Manual Forward Event before failover Message generate Case

11:53:33 Call Generated(78121)
11:53:36 Call Generated(78123)
11:55:05 AES#2 Failure(Disconnect LAN Cable) occurred
11:55:22 Generate Manual Forward Event before failover Message generate(78123)
11:56:09 Event113 Generated
11:56:49 Event112 Generated
12:00 Generate Manual Forward event 3 min. later after AES connector perfored Failover to AES#1(78121)
6min later, when Generate Manual Forward Event again, No error log was generated in OD trace.

Best regards, K.Yamahara

Hi Martin-san,

Thank you for your reply.

I understood it.
So, please close this ticket.

Here after are information for you, Just in case.
I also got answer from Genesys-Japan.
They said that two HA-mode Genesys T-server can support single AES.
Then I got below their Deployment Guide.

Actually, I can not understood answer from Genesys-Japan due to find below description.
Then I'm still discussing this with them.
-----
Supported High-Availability Configurations(P185-)
Warning!
For high-availability, any T-Server pair in warm or hot standby must have two AES servers to allow messages to go to both the primary and backup T-Server. Otherwise, messages are split between the primary and backup T-Server.
-----

Best regards, K.Yamahara