Same question for me !

I haven't setup SQL cluster since PU9 to be honest, but for me I just specified the CLUSTER name, rather than the server name when running X3 console... i.e. from my X3 Apps server I connected to my SQL cluster connection using SSMS with SQLCLUSTER\X3TEST (Servername\instance) so when I setup in X3 console I just gave SQLCLUSTER as the database server name.

(Remember that you have to use Manual setup for the database in the X3 console when using SQL cluster....)

Necroposting since I have recently received an order for this.

Sage kb: https://support.na.sage.com/selfservice/viewdocument.do?noCount=true&externalId=110147&sliceId=1&isLoadPublishedVer=&docType=kc&docTypeID=DT_Article&stateId=11501&cmd=displayKC&dialogID=720800&ViewedDocsListHelper=com.kanisa.apps.common.BaseViewedDocsListHelperImpl&openedFromSearchResults=true

Basically:

1. For SQL side, have a DBA expert on hand for SQL cluster upkeep. Notify it is: Active/Passive.

2. For X3 console side, see Mike reply above.

I am interested if there is any difference between the Manual configuration or the usual console configuration through AdxAdmin. I know the installation document mentioned briefly but never dive in on it.

There is no difference in the database that is setup by using manual or adxadmin.  In essence, when using AdxAdmin the database create script is sent to the DB server to be run by AdxAdmin service, but if using manual option the same script is generated but is left for you to manually copy and execute.

hope this clarifies for you

You need to install the database via the X3 console in manual mode, don't install the adxadmin component, and configure the database like if it were a not named instance by not specifying the instance name.
DO NOT CONFIGURE the X3 application  BEFORE THE DATABASE HAS BEEN CREATED.
Take the script created by the console and build the database on primary. Don't activate the availability group yet.
Configure X3 the application
Back up the X3 database to initialize the secondary node of the AG

Restore it on the secondary in no recovery

Create the AG, create the AG listener

Extract the SQL logins from primary with their link to SQL user and passwords as hash

Update the solution.xml with the listener name in servername and MSSQLSERVER in sqlinstance

reconfigure the runtime.