8 Replies Latest reply: Jan 15, 2014 11:34 PM by 0ed4708b-04cd-45da-b116-8087081edb74 RSS

Runtime error - extra root element - MDS

0ed4708b-04cd-45da-b116-8087081edb74 Newbie
Currently Being Moderated

I have an issue which is killing my remaining neurons and hopefully someone can help me.

 

We have implemented a service which is working fine in two of our dev environments (lets call them Dev1 and Dev2). Unfortunately when deployed into a third environment (lets call it Dev3) there is a transformation not working properly.


Basically I have two services developed in JDev where service X invokes Service Y. When I check the payload received in Service Y I got an extra root element which I do not have in our DEV environments and which is actually the operationName defined in the MDS.

 

Simplified example:

 

Paylod in Service Y in Dev 1 and Dev2

Paylod inService Y in Dev 3 (error Case)

<receiveBus_InputVariable>

<part  name="request">

<cor:policyInformation>
<cor:metadata>
<cor:userID>SAM</cor:userID>

 

</cor:metadata>

<receiveBus_InputVariable>

<part  name="request">

<TransformBusToTIA>
<inp1:policyInformation>
<policyInformation>
<tns:metadata>
<tns:userID>SAM</tns:userID>

 

</tns:metadata>

 

..........


Note: see the extra TransformBusToTIA

 

Nevertheless when I deploy all the components in Dev3 without using MDS everything works fine.

What I know/tried:

  • All Dev1/2/3 share the same base of software (SOA Suite 11.1.1.3, Weblogic 10.3)
  • All initialization parameters for startManagedWebLogic are the same across environments except for one which I don't think its related: (-DUseSunHttpHandler=true)
  • I restarted server, redeployed services, cleaned MDS, redeployed MDS, the erratic behavior remains
  • Invoking service Y from SoapUI works fine in all environments with or without MDS, which can indicate that the problem is in the top layer service (service X)?
  • The deployment script is ant based and all deployments in environments are done with the same source.
  • If I do not use the configuration plan for MDS at deployment time and use localhost references instead, we do not have this erratic behavior in DEV3.
  • Another thing i found to be different in DEV3 is some calls to external services which add the ws-adressing namespace to the reply where in DEV1 and DEV2 this does not happen. Dunno if it is related, but anyway i have no error in any other service which is using MDS.

 

 

Can the expected behavior of a XSLT transformation change across environments, considering that the deployment Jars of the projects and Metadata (MDS) are exactly the same?

None of the services have any policy attached, is there any possibility that SOA is adding the namespace “wsa="http://www.w3.org/2005/08/addressing(WS-Addressing) which ruins the transformation?

 

Thanks,

André

  • 1. Re: Runtime error - extra root element - MDS
    PuneetRekhade Journeyer
    Currently Being Moderated

    Andre, I am sure, you must have checked this.. but could you just confirm if the XSLT files are same in dev3 and dev1/2 env ? Because extra element being added into the transformation step could be the result of the XSLT only. Frankly, I've very little doubts on anything wrong with MDS.

  • 2. Re: Runtime error - extra root element - MDS
    0ed4708b-04cd-45da-b116-8087081edb74 Newbie
    Currently Being Moderated

    Hi PuneetRekhade. Thanks for you answer.

     

    I know the source is the same, since it is exactly the same jar being deployed. Is there any way to confirm the deployed xsl?

    It is a bit strange this behavior since the caller (service X) seems to send the correct payload, but service Y already receives it with the extra tag. The error is generated on the xsl transformation but apparently the error occurs in the invocation.

     

    Also i would like to confirm if it is normal that i find the MDS deployments under "IP:PORT/soa-infra/services/LogicalPartition/serviceName/apps/Metadata/etc..."

    It seems its replacing oramds: for the service deployment path.

     

    Best regards,

    André

  • 3. Re: Runtime error - extra root element - MDS
    PuneetRekhade Journeyer
    Currently Being Moderated

    Yes, you can easily verify the contents of the deployed XSL. (1) Unzip the contents of the jar and you should be able to find the relevant xslt file under "xsl" folder. (2) You can extract the deployed composites (in the form of a jar) from the respective environments and then, do a mass-compare of such extracted files for a detailed file-level comparison.

     

    Looks like, the MDS path you are referring to, is taken from a deployed / concrete wsdl of a service and "LogicalPartition" being the name of the domain, where this service has been deployed onto the server.

    If you could extract the jar mentioned above and look at the wsdl there, if present, then, I expect that it contains references to the MDS Schema using the "oramds" protocol.

     

    Hope it helps.

  • 4. Re: Runtime error - extra root element - MDS
    0ed4708b-04cd-45da-b116-8087081edb74 Newbie
    Currently Being Moderated

    The deployed jar in the environment DEV3 has no relevant difference from the the DEV1/2 jars.

    The WSDL's are pointing correctly to the MDS Schema using the oramds protocol, but this is something we knew already.

     

    We have found out that the DEV3 is not a copy of DEV1/2 but a new clean install. What configurations can happen at installation time that would lead to such a behavior discrepancy? Does anyone know?

     

    As stated before the deployment with MDS works in other environments so it must be something related to SOA Suite configurations, specially with MDS since if i deploy using a configuration plan to point to localhost it will work.

     

    Thanks,

    André

  • 5. Re: Runtime error - extra root element - MDS
    PuneetRekhade Journeyer
    Currently Being Moderated

    The deployed jar in the environment DEV3 has no relevant difference from the the DEV1/2 jars.

    I guess, you mean that there is no code difference in the bpel, xsl,xsd files other than the environment url's, which should be different for different environments.

     

    We have found out that the DEV3 is not a copy of DEV1/2 but a new clean install.

    Install of what ? SOA Suite ? Or the composites ?

     

    I would suggest that you check and compare the content of the wsdl / xsd files, which are being referred from the services. I think, the file contents of MDS might be different for DEV3 than those DEV1/2. Just to be double-sure.

  • 6. Re: Runtime error - extra root element - MDS
    0ed4708b-04cd-45da-b116-8087081edb74 Newbie
    Currently Being Moderated

    Yes on the first topic. Besides the url's there are no differences.

     

    Install of the SOA Suite. While DEV1 and DEV 2 are just identical virtual images, DEV3 had a SOA Suite clean install.

     

    All the xsd and wsdl's were compared and no differences exists. I believe here we are dealing with an environment configuration problem. Its the only reasonable explanation i find since since all the MDS/Composites deployments and source are exactly the same.

     

    Thanks for your time and tips PuneetRekhade.

     

    Cheers,

    André

  • 7. Re: Runtime error - extra root element - MDS
    PuneetRekhade Journeyer
    Currently Being Moderated

    Although the SOA installations might be different, still, I am not able to understand the rationale behind the anamoly. But somewhere, I think, that soa suite might not be the real culprit. Anyways, do post the answer, whenever you get one.. I would be glad to hear the secret !

    Cheers (Hic!)

  • 8. Re: Runtime error - extra root element - MDS
    0ed4708b-04cd-45da-b116-8087081edb74 Newbie
    Currently Being Moderated

    Hi.

     

    Just to state we solved the problem.

    We had an outdated reference in a composite.xml to other server (which had the same developments installed) which apparently was generating inconsistency in namespaces.

    After correcting this reference everything work fine.

     

    Thanks for the support Puneet.