AssignMessage dropping namespace elements in XML payloads (e.g. SOAP)

Not applicable
My API proxy provides a REST API over a SOAP backend. As part of this I have some AssignMessage policies to build SOAP requests for the target from the proxy request. While this works ok it seems if I ever edit the policy using the Apigee Edge management UI (which I might occasionally do for test/debug) then the namespace elements from the XML payload are lost. Example (headers redacted)...
<Set>
  <Verb>POST</Verb>
  ...
  <Payload contentType="text/xml">
    <soap:Envelope
      xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
      xmlns:v9="http://foo/bar/ws/fof/V1_00"
      xmlns:v91="http://foo/bar/ws/common/V1_00">
      <soap:Header>
      ...
      </soap:Header>
      <soap:Body>
        <v9:CreateRequest>
          <v9:Criteria Instance="{Foo.Instance}">
            <v91:Id>{saved.Param.RequestId}</v91:Id>
            <v91:Remarks>{saved.Param.RequestInfo}</v91:Remarks>
            <v91:Locations>
              <v91:Location>{saved.Param.LocationId}</v91:Location>
            </v91:Locations>
          </v9:Criteria>
        </v9:CreateRequest>
      </soap:Body>
    </soap:Envelope>
  </Payload>
</Set>
Becomes this...
<Set>
  <Verb>POST</Verb>
  ...
  <Payload contentType="text/xml">
    <Envelope
      xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
      xmlns:v9="http://foo/bar/ws/fof/V1_00"
      xmlns:v91="http://foo/bar/ws/common/V1_00">
      <Header>
      ...
      </Header>
      <Body>
        <CreateRequest>
          <Criteria Instance="{Foo.Instance}">
            <Id>{saved.Param.RequestId}</Id>
            <Remarks>{saved.Param.RequestInfo}</Remarks>
            <Locations>
              <Location>{saved.Param.LocationId}</Location>
            </Locations>
          </Criteria>
        </CreateRequest>
      </Body>
    </Envelope>
  </Payload>
</Set>
Is this a bug, am i misusing AssignMessage or is my XML wonky? Note that the namespace elements are not displayed in the editor pane but my proxy will continue to work as long as I don't edit/save the policy.
Solved Solved
2 4 781
1 ACCEPTED SOLUTION

As a workaround, you can download (export) the proxy bundle, then edit it "offline" (outside of the UI), and then upload (import) the proxy bundle again. This will avoid the problem in the UI. As another potential workaround, you may be able to use the older proxy editor. There has recently been an update to the proxy editor. In the proxy editor window, there's a link you can click to use the older proxy editor. See the screenshot below. This may allow you to avoid the problem as well.

1058-screenshot-20150902-102041.png

View solution in original post

4 REPLIES 4

Looks like a UI issue @Adam Johnston , I am also able to reproduce this, will create a issue and let know the status Thanks,

Thanks Mukundha!

As a workaround, you can download (export) the proxy bundle, then edit it "offline" (outside of the UI), and then upload (import) the proxy bundle again. This will avoid the problem in the UI. As another potential workaround, you may be able to use the older proxy editor. There has recently been an update to the proxy editor. In the proxy editor window, there's a link you can click to use the older proxy editor. See the screenshot below. This may allow you to avoid the problem as well.

1058-screenshot-20150902-102041.png

We primarily use offline editing with our proxy code in source control. This is a problem that only is only seen if someone edits the proxy using the web UI (e.g. to temporarily use a test target).