1 Reply Latest reply on Jun 12, 2012 1:24 PM by Viktor.Jarolim-Oracle

    Invalid Message during GetOrder.Response

      Hi All,

      Currently we are encountering issue whereby we invoke GetOrder.Response using this script fn:root(.)/oms:GetOrder.Response, and there is fallout response being returned to OSM with this format :

      <GetOrder.Response xmlns="urn:com:metasolv:oms:xmlapi:1">
      <RequestedDeliveryDate>2012-05-29T13:43:45 CEST</RequestedDeliveryDate>
      <ExpectedStartDate>2012-05-29T13:43:45 CEST</ExpectedStartDate>
      <ExpectedOrderCompletionDate>2012-05-30T05:15:24 CEST</ExpectedOrderCompletionDate>
      <_root index="0">
      <Fallout index="61">
      <waitingResponse index="62">
      <component index="1338347726181">
      <Id index="1338347726182">1eb696d8-fe4c-408a-b67d-976dc8b93256</Id>
      <status index="1338347726183">nowait</status>
      <component index="1338347726290">
      <Id index="1338347726291">ee376008-b9e0-463d-866c-46cd4ac6b3a7</Id>
      <status index="1338347726292">nowait</status>
      <component index="1338347726417">
      <Id index="1338347726418">4f67c313-838b-444c-b127-37409f07c783</Id>
      <status index="1338347726419">nowait</status>
      <component index="1338347726544">
      <Id index="1338347726545">b6d433c2-8577-4d21-a9eb-5881ecafc17a</Id>
      <status index="1338347726546">wait</status>
      <History index="63"/>
      <validation index="64"/>
      <inFallout index="65"/>
      <orderAbortStatus index="66"/>

      Instead of it is returning the correct data, it returns Fallout with 'nowait' and 'wait' status in the body.
      Have you guys ever encountered this issue before?
      Looking for your feedback.

      Thank you.

        • 1. Re: Invalid Message during GetOrder.Response
          Hi, from my point of view this is a normal GetOrder.Response response.
          What sort of automator are we talking about?
          If this is an order state event or a jeopardy event, the data returned by the GetOrder.Response depends on the view (now called Query Task) configured for the user executing the automator.
          Since the user may be a member of more workgroups and different views can be associated for the given order for each workgroup, the OSM engine will pick one (at random) and that one will be used.
          In order to make sure the data provided by the OSM engine as the input of your automator corresponds to a particular view, do one of the following:

          a) make sure the user executing the automator is a member of exactly one workgroup and that waorkgroup is associated with the Query Task you want to use for the given Order; you may have added the user executing your automator to some additional workgroups

          b) use explicit call to xml api via the context object where you can specify the view yourself in the GetOrder.Request and use the data returned for the processing rather than the data given in the initial input ; this way you can choose yourself among the set associated to the user via the different workgroups

          sample piece of xquery code:

          let $inputData := fn:root(.)/oms:GetOrder.Response
          let $xmlApiRequest :=
          <GetOrder.Request xmlns="urn:com:metasolv:oms:xmlapi:1">
          <OrderID> { $inputData/OrderID/text() } </OrderID>

          let $xmlApiRequestStr := saxon:serialize($xmlApiRequest, <xsl:output method='xml' omit-xml-declaration='yes' indent='yes' saxon:indent-spaces='4'/>)

          let $xmlApiResponseString := context:processXMLRequest($context, $xmlApiRequestStr)
          let $xmlApiResponseDoc := saxon:parse($xmlApiResponseString)
          let $completeOrderData := $xmlApiResponseDoc/*

          this sample is just a prototype; normally you would want to check the response is a correct one and not a GetOrder.Error; anyway the principle also applies to your case if the issue is what I suspect it is

          Viktor Jarolim