Java API (UC4.jar) with Automic V21

[Silke Zaech]

Hi all,

we are preparing the Automic Migration from 12.03.07 to V21.0.5 and are testing all our interfaces. But, now we have a issue by trying to connect the Automic Engine over the Java API (uc4.jar). 

We are using the parameter -trustedFolderPath and despite the right Certificate is in place and valid, we cannot connect and get following error message:

Connection to the Automation Engine could not be established: System.Management.Automation.MethodInvocationException: Exception calling "open" with "5" argument(s): "Failed to connect to [dns.name].com:[port]" ---> 
java.io.IOException: Failed to connect to [dns.name].com:[port] ---> java.util.concurrent.ExecutionException: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure ---> javax.net.ssl.SSLHandshakeException: Received 
fatal alert: handshake_failure
   at org.eclipse.jetty.io.ssl.SslConnection.DecryptedEndPoint.rethrow(Exception )
   at org.eclipse.jetty.io.ssl.SslConnection.DecryptedEndPoint.fill(ByteBuffer buffer)
   at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.process()

does anybody know this issue and how it could be solved?
When we use the uc4.jar suggested in following article, we can establish the connection. But without TLS:

ApplicationInterface/Java Api (Uc4.jar) and Automic v21 | Automic Workload Automation (broadcom.com)

Thanks a lot and regards,

Silke

[Michael Dolinek]

Hi @Silke Zaech 

you have to be careful which versions are used where.
* v12.3.9 HF2's UC4.jar can be used to connect to any AE v12.3.9 or v21.0.4 (and up) to the CP port (standard 2217) without certificates
* current v21.0.5's UC4.jar can be used to connect to any AE v21.0.5 (and up) to the JCP port (standard 8443) with certificates

Hope this helps
Michael

[Michael A. Lowry]

@Michael Dolinek:
Are there any differences between the AWA Java Application Interface and the AAKE Java Application Interface?

[Michael Dolinek]

Hi @Michael Lowry

the Offerings AA and AAKE are based on the same/identically (source) files. But files needed for an installation on K8s are only part of AAKE.
The challenges of an K8s environment are port and file access inside and outside of the cluster and the usage of the proper certificate (e.g. Ingress vs. AE's JCP) when connecting to the AE.

Michael

[Michael A. Lowry]

We're using AAKE already so we're familiar with the installation & configuration differences.

I asked about possible Java API differences only because the documentation is duplicated in two difference locations on docs.automic.com.

If the Java APIs are identical between AWA & AAKE, why bifurcate the docs?

[Michael A. Lowry]

Perhaps @Gabi Oberreiter knows the answer.

[Silke Zaech]

Hi @Michael Dolinek,

thank you very much for your explanations, that's good to know too.

We have Automic Engine V21.0.5+HF2 installed and when I use the uc4.jar from the Major Version V21 I have still handshake failures.

We are not using the standard JCP Port (8443) but the test with "invoke-webRequest -uri .... " is successfully with the port I got from our AE Administrators. 

I am working for an Automic Workload developing Team and we are not AE Administrators.

What we are doing in detail:

For us it is essential to be able to develop modern scripts (Pyton, Powershell) with the Automic Java API.
For that, we convert the uc4.jar to automic.dll and till now it has worked perfectly!!

We work inhouse with a PublicRoot Certificates, pre-installed on all our servers. 
So, we have the certificates on our Windows Application Server in the Windows Cert Store. 
From there, we have exported the cert and converted it to the pem (ASCII) Format and have tried to connect with the -trustedFolderPath Parameter.

But we get this kind of java handshake failure. We have checked the connections, everything, also with our Certificate Experts inhouse. But haven't found the root cause. 

The same scenario with the uc4.jar from Version 12.03.09+HF2 and without TLS Connection to the V21 Engine works properly.

Do you have any idea how to solve that?
Thanks a lot in advanced and regards, 

Silke



This is the whole error message:

Connection to the Automation Engine could not be established: 
System.Management.Automation.MethodInvocationException: Exception calling "open" with "5" argument(s): "Failed to connect to 
[AE DNS Name]:[Port]" ---> java.io.IOException: Failed to connect to @Michael Dolinek@Michael Dolinek ---> 
java.util.concurrent.ExecutionException: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure ---> 
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
   at org.eclipse.jetty.io.ssl.SslConnection.DecryptedEndPoint.rethrow(Exception )
   at org.eclipse.jetty.io.ssl.SslConnection.DecryptedEndPoint.fill(ByteBuffer buffer)
   at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.process()
   --- End of inner exception stack trace ---
   at com.uc4.communication.WebSocketConnection..ctor(String hostname, Int32 port, Properties options, DebugAndTraceListener traceListener, 
String trustedCertFolderPath)
   --- End of inner exception stack trace ---
   at com.uc4.communication.WebSocketConnection..ctor(String hostname, Int32 port, Properties options, DebugAndTraceListener traceListener, 
String trustedCertFolderPath)
   at com.uc4.communication.Connection..ctor(String hostname, Int32 port, Properties options, DebugAndTraceListener traceListener, String 
trustedCertFolderPath)
   at com.uc4.communication.Connection.open(String servername, Int32 port, Properties options, DebugAndTraceListener traceListener, String 
trustedCertFolderPath)
   at CallSite.Target(Closure , CallSite , Type , Object , Object , Object , Object , String )
   --- End of inner exception stack trace ---
   at System.Management.Automation.ExceptionHandlingOps.CheckActionPreference(FunctionContext funcContext, Exception exception)
   at System.Management.Automation.Interpreter.ActionCallInstruction`2.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
Connection to the Automation Engine could not be established: System.Management.Automation.MethodInvocationException: Exception calling "open" with "5" argument(s): "Failed to connect to @Michael Dolinek@Michael Dolinek@Michael Dolinek ---> java.util.concurrent.ExecutionException:   
  javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure ---> javax.net.ssl.SSLHandshakeException: Received fatal alert:    
 handshake_failure
   at org.eclipse.jetty.io.ssl.SslConnection.DecryptedEndPoint.rethrow(Exception )
   at org.eclipse.jetty.io.ssl.SslConnection.DecryptedEndPoint.fill(ByteBuffer buffer)
   at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.process()
   --- End of inner exception stack trace ---
       at com.uc4.communication.WebSocketConnection..ctor(String hostname, Int32 port, Properties options, DebugAndTraceListener traceListener, S 
   tring trustedCertFolderPath)
   --- End of inner exception stack trace ---
       at com.uc4.communication.WebSocketConnection..ctor(String hostname, Int32 port, Properties options, DebugAndTraceListener traceListener, S 
   tring trustedCertFolderPath)
       at com.uc4.communication.Connection..ctor(String hostname, Int32 port, Properties options, DebugAndTraceListener traceListener, String tru 
   stedCertFolderPath)
       at com.uc4.communication.Connection.open(String servername, Int32 port, Properties options, DebugAndTraceListener traceListener, String tr 
   ustedCertFolderPath)
   at CallSite.Target(Closure , CallSite , Type , Object , Object , Object , Object , String )
   --- End of inner exception stack trace ---
   at System.Management.Automation.ExceptionHandlingOps.CheckActionPreference(FunctionContext funcContext, Exception exception)
   at System.Management.Automation.Interpreter.ActionCallInstruction`2.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)

[Michael Dolinek]

Hi @Silke Zaech 

some questions:
*) which tool are you using to generate this automic.dll
*) which Java version incl. vendor is used during that generation process
*) are there any additional dlls required during runtime (according to the docu of the conversion tool's vendor)
*) does it work with the automic.dll (incl. IKVM dlls) provided with v12.3.9 HF2 (without certificates and connecting to the CP 2217)
*) does the intended setup work with an pure Java implementation

Thank you for answering
Michael

[Silke Zaech]

Good morning @Michael Dolinek 

1) we have always used IKVM Converter, and it worked always perfectly.
2) we have AdoptOpenJDK JRE 8** and 11** installed, no other vendor involved.
3) yes, we have to use the IKVM*.dll's
4) yes, it works perfectly.
5) haven't tried by myself yet. We are not Java Developers and have not planed to be it. 
     Especially, with converting the uc4.jar, we had or have fully access to all classes...

Best regards, Silke

[Michael Dolinek]

Hi @Silke Zaech 

As http://www.ikvm.net is no longer online I can not prove my statement but based on our experience IKVM works only (reliable) with jar-files based on Java 7.
All/most of the Java based components of Automic Automation v21 are build with Java 8. So the original IKVM can not be used to create an Automic.dll but there is "IKVM revived" on GitHub (https://github.com/ikvm-revived/ikvm) which should work with Java 8 based jar-files. But we do not have any experience.

According to the info of JNBridge (https://jnbridge.com/software/jnbridgepro/overview) it should be possible that developers can integrate newest uc4.jar into their .Net-project. But there is no experience on our side.

Michael

[Silke Zaech]

Good morning @Michael Dolinek 

thank you very much for your response.
Then you are more likely to assume it is a issue by converting the uc4.jar, then by the authorization with the certificates?

By the way,
we consider it as really bad, that Automic doesn't provide the right automic.dll by themselves. Especially because, for ARA they have provided it and so they gave place for that kind of approach.
Do you know why? Doesn't matter, that it won't be supported by any user failures, it would open the Automation World to more modern developments.

Best regards, Silke

[Martin Jankowski]

Hi @Silke Zaech
we used the (self-generated, IKVM version V 8.1.5717.0 including a Java VM version 8) automic.dll for more than 10 years, up to version V21.0.2 also with TLS successfully.
Since version V21.0.4, however, this no longer works via TLS. Our analyses show that the client and server cannot agree on a Cypher suite. 
There seems to be a way to use the Bouncy Castle provider, at least I was able to establish a TLS connection to an AE version 21.0.5 ...
If you are interested, feel free to contact me

------------------------------
[CompanyName]
------------------------------

[Julian Dick]

Hello @Martin Jankowski ,

I would also like if you would share with me how you managed to successfully establish a TLS connection with IKVM under v21.0.5.

I tried myself to get it working but i cant get past the handshake failure error.

Best regards and good Weekend, Julian