0
votes

I have configured a WCF-WebHttp BizTalk Request/Response Static pipeline adaptor with the following URL mapping

<BtsHttpUrlMapping>
<Operation Name="Query_ADM" Method="GET" Url="{MYVARIABLE}" />
</BtsHttpUrlMapping>

In the Variable Mapping I have set the variable name MYVARIABLE to a property called id in the defining schema of the message. I have set the property namespace of the defining schema - in the variable mapping - which is also published to the same application.

The id has been promoted in the schema and I can see this promotion if I trace this through the tracked message events.

However at the point there the logical send/receive port sends the message through the physical port - it appears the promotion of the id field is dropped.

There is a transmission failure message with

The adapter failed to transmit message going to send port "MY_PORT" with URL "http://myurl.dev.application.com/api/v2/crm/accounts/". It will be retransmitted after the retry interval specified for this Send Port. Details:"System.ArgumentException: The path variable 'MYVARIABLE' in the UriTemplate must be bound to a non-empty string value.

Everything looks setup okay? Does anyone have any ideas? Thanks.

Here's the schema with promoted (and distinguished) id property field.

Schema

enter image description here

2

2 Answers

0
votes

In this case you seem to be using a Distinguished Field, instead of a Property Field. Distinguished fields are only accessible within orchestrations. See here for an explanation.

You need to create a property schema in order to promote your property to a Property Field.

(Make sure you're using an XMLTransmit pipeline on the send part of the WCF-WebHttp port (or any pipeline with an XML assembler component). Otherwise the adapter won't recognise promoted properties in the message.)

0
votes

Okay - so when setting the variable mapping it seems I was using the wrong property namespace. I was using the namespace of the XSD that contained the property when I should have been explicitly using the namespace of the property promotion schema itself. That appears to have resolved the issue.