'Could not deserialize result from HTTP invoker remote service' error when opening/editing workflows in RSA Identity Governance & Lifecycle
3 years ago
Originally Published: 2017-11-27
Article Number
000040606
Applies To
RSA Product Set: RSA Identity Governance & Lifecycle
RSA Version/Condition: 7.x
 
Issue
The following error occurs in the RSA Identity Governance & Lifecycle user interface when opening or editing any workflow:
 
Could not deserialize result from HTTP invoker remote service
[http://<server-name>/wpServices/ProcessService]; nested exception is
java.io.InvalidClassException: com.workpoint.common.data.table.TableData;
local class incompatible: stream classdesc serialVersionUID = 8915539405905761180,
local class serialVersionUID = 874241357800048193:


The same error is in the aveksaServer.log (/home/oracle/wildfly/standalone/log/aveksaServer.log): 
WARN [wp.utils.WpUtils] (default task-182) [ProcessesService] 
Could not deserialize result from HTTP invoker remote service 
[http://<server-name>/wpServices/ProcessService]; nested exception is 
java.io.InvalidClassException: com.workpoint.common.data.table.TableData; 
local class incompatible: stream classdesc serialVersionUID = 8915539405905761180, 
local class serialVersionUID = 874241357800048193: 
org.springframework.remoting.RemoteAccessException: 
Could not deserialize result from HTTP invoker remote service 
[http://i<server-name>/wpServices/ProcessService]; nested exception is 
java.io.InvalidClassException: com.workpoint.common.data.table.TableData; local class incompatible: 
stream classdesc serialVersionUID = 8915539405905761180, local class serialVersionUID = 874241357800048193 
at org.springframework.remoting.httpinvoker.HttpInvokerClientInterceptor.convertHttpInvokerAccessException(HttpInvokerClientInterceptor.java:212) 
[spring-web-4.2.8.RELEASE.jar:4.2.8.RELEASE] 
at org.springframework.remoting.httpinvoker.HttpInvokerClientInterceptor.invoke(HttpInvokerClientInterceptor.java:147) 
[spring-web-4.2.8.RELEASE.jar:4.2.8.RELEASE] 
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) 
[spring-aop-4.2.8.RELEASE.jar:4.2.8.RELEASE] 
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:208) 
[spring-aop-4.2.8.RELEASE.jar:4.2.8.RELEASE] 
at com.sun.proxy.$Proxy282.queryByID(Unknown Source)

Please refer to RSA Knowledge Base Article  000030327 -- Artifacts to gather in RSA Identity Governance & Lifecycle to find the location of the aveksaServer.log file for your specific deployment if you are on a WildFly cluster or a non-WildFly platform.
 
Cause
This error indicates an inconsistency between the version of the Workflow server engine and the Workflow Architect which occurs when the Aveksa ear and Workflow Architect ear files are not deployed correctly.
 
Resolution
Deploy the aveksa and workflow architect ear files again to have this issue fixed.
  1. Login to the RSA Identity Governance & Lifecycle application server as the oracle user. If this is a cluster, login to the server defined as the Domain Controller.
  2. Run the command below to find the IP address on which the server is listening: 
    netstat -ltn | grep 9999
    You should see output similar to the below: 
    tcp        0      0 127.0.0.1:9999          :::*                    LISTEN

    Use the IP address from the above command in the subsequent steps.

  3. Check which ear files are deployed with the following command 
    $AVEKSA_HOME/wildfly/bin/jboss-cli.sh -c --controller="127.0.0.1:9999" --command="deployment-info"
    You should see output similar to the below:
NAME                   RUNTIME-NAME          PERSISTENT ENABLED STATUS
aveksaWFArchitect.ear aveksaWFArchitect.ear  true       true    OK
aveksa.ear            aveksa.ear             true       true    OK
 It is possible you might see output such as the following if you have previously deployed the aveksa ear file manually and did not rename or copy it to aveksa.ear before deployment.
NAME                              RUNTIME-NAME                      PERSISTENT ENABLED STATUS
aveksaWFArchitect.ear             aveksaWFArchitect.ear             true       true    OK
<name other than aveksa.ear>      <name other than aveksa.ear>      true       true    OK
  1. Undeploy the ear files (Standalone) 
    $AVEKSA_HOME/wildfly/bin/jboss-cli.sh -c --controller="127.0.0.1:9999" --command="undeploy <name of deployed aveksa ear file>"
$AVEKSA_HOME/wildfly/bin/jboss-cli.sh -c --controller="127.0.0.1:9999" --command="undeploy aveksaWFArchitect.ear"
  2. Undeploy the ear files  (Clustered) 
    $AVEKSA_HOME/wildfly/bin/jboss-cli.sh -c --controller="127.0.0.1:9999" --command="undeploy <name of deployed aveksa ear file> --server-groups=img-server-group"
$AVEKSA_HOME/wildfly/bin/jboss-cli.sh -c --controller="127.0.0.1:9999" --command="undeploy aveksaWFArchitect.ear --server-groups=img-server-group"
  1. Deploy the ear files. (Standalone) 
    $AVEKSA_HOME/wildfly/bin/jboss-cli.sh -c --controller="127.0.0.1:9999" --command="deploy $AVEKSA_HOME/archive/<name of aveksa ear file to be deployed>
--name=aveksa.ear --runtime-name=aveksa.ear"
$AVEKSA_HOME/wildfly/bin/jboss-cli.sh -c --controller="127.0.0.1:9999" --command="deploy <directory path>/aveksaWFArchitect.ear"
  2. Deploy the ear files. (Clustered) 
    $AVEKSA_HOME/wildfly/bin/jboss-cli.sh -c --controller="127.0.0.1:9999" --command="deploy $AVEKSA_HOME/archive/<name of aveksa ear file to be deployed>
--name=aveksa.ear --runtime-name=aveksa.ear --server-groups=img-server-group"
$AVEKSA_HOME/wildfly/bin/jboss-cli.sh -c --controller="127.0.0.1:9999" --command="deploy <directory path>/aveksaWFArchitect.ear --server-groups=img-server-group"

Related Articles

Trending Articles

Don't see what you're looking for?