Azure BizTalk Services – My Learnings 5 – Non-Existent Pipeline Endpoint …Url = /agreements/1/send

Posted: June 15, 2014  |  Categories: BizTalk Uncategorized

I have been creating some of the Microsoft Azure code examples and I always choose to create the projects from scratch rather than downloading the code because I think that is a good way to learn. I find that the errors that you get and then solve along the way are immensely valuable for your understanding. Thus I am going to record some of these errors and their solutions.

Recently I have been studying Nitin Mehotra’s “Use Windows Store Apps to Send Messages to BizTalk Service Bridges“ which is a uber project containing an eclectic mix of;

    • Bing maps
    • SendGrid email service
    • Azure Blob storage
    • Connectivity to on-premise LOB applications ( SQL server via relay – “look Mum no firewall burn required”)
    • Azure Cloud service
    • Azure Trading Partner Management using custom settings

As the summary suggests this has been a bit of mission not only because some of the projects have been superseded with newer artifacts e.g. SendGrid is incremented several versions and a Windows 8.1 is available. I had to refactor the solution to use these newer version but that is not what i want to write about here.

Once I had all the artifacts deployed I begun to test the application as described here. Immediately things did not work. I have reproduced Nitin’s process diagram below to make the explanation of the errors clear.

CloudCar application flow

I saw that the purchase order message was stored in a purchase order blob ( steps 1 to 2 in the diagram) but it did not get picked up and moved to the supplier blob. I looked at the Microsoft Azure BizTalk services tracking page but no errors where evident.


It was not until I queried the WADSLogTable that I saw some errors. the first error I saw was “ Non-Existent Pipeline Endpoint. RequestID = <some guid>. Url = /agreements/1/send.;TraceSource ‘Microsoft – Integration – Pipeline Service Event”.  I looked at the BlobPollerRole solution which is a cloud service that sends the purchase order message to the supplier blob. I found /agreements/1/send in the ServiceConfiguration.Cloud.cscfg and ServiceConfiguration.Local.cscfg.

<?xml version=”1.0″ encoding=”utf-8″?>
<ServiceConfiguration serviceName=”BlobPollerRole” xmlns=”” osFamily=”4″ osVersion=”*” schemaVersion=”2013-10.2.2″>
<Role name=”BlobPollerWorkerRole”>
<Instances count=”1″ />
<Setting name=”Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString” value=”DefaultEndpointsProtocol=https;AccountName=bizstorage;AccountKey=not my guid/>
<Setting name=”ACSAddress” value= />
<Setting name=”IssuerName” value=”owner” />
<Setting name=”IssuerKey” value=”not my key/>
<Setting name=”PipelineAddress” value= />
      <Setting name=”ContainerName” value=”purchaseorder” />
<Setting name=”CloudStorageAccountConnectionString” value=”DefaultEndpointsProtocol=https;AccountName=cloudcardstore;AccountKey=not my key/>
<Setting name=”ContentTypeValue” value=”application/xml” />

Now looking at the bridges page of Microsoft Azure BizTalk Services the problem and solution is obvious.


I had recreated the agreement several times and each time the agreement bridge had been incremented, thus rather than having an agreements/1/send endpoint i had a agreements/3/send endpoint. I edited the cscfg configuration files and redeployed the BlobPollerRole solution. The error now disappears from the WADSLog but I saw a new error in the Azure BizTalk Services tracking screen. That will be the subject of my next post.

In summary if you delete and recreate a trading partner agreement in Azure the endpoints will change and you must update any code that references that endpoint to the correct value.


Back to Top