000035783 - 'Could not deserialize result from HTTP invoker remote service' error when opening/editing workflows in RSA Identity Governance & Lifecycle

Document created by RSA Customer Support Employee on Dec 23, 2017Last modified by RSA Customer Support Employee on Jan 20, 2020
Version 5Show Document
  • View in full screen mode

Article Content

Article Number000035783
Applies ToRSA Product Set: RSA Identity Governance & Lifecycle
RSA Version/Condition: 7.x
 
IssueThe 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.
 
CauseThis 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.
 
ResolutionDeploy 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"

Attachments

    Outcomes