Shashi

when you have escape characters in the string the liquid template fails

Shashidharan Krishnan — Mon, 29 Jan 2018 12:29:01 GMT

I came across a scenario, where I got bad request error when I have double quotes(“) in my incoming string property while performing json to json transforming using liquid template. When there is not double quotes it works as expected.

My Liquid Template: performing a simple append of first name and last name

{ "fullName": "{{content.FirstName | Append: ' ' | Append: content.LastName}}",}

When input message is:

{ "FirstName": "Shashidharan", "LastName" : "Krishnan" }

When input message contains doubles qoutes, which is still a valid json message.

{ "FirstName": "\"Shashidharan","LastName" : "Krishnan" }

we get bad request error

"body": { "Code": "IncorrectLiquidTransformOutputType", "Message": "An error occurred while converting the transformed value to JSON. The transformed value is not a valid JSON. 'After parsing a value an unexpected character was encountered: S. Path 'fullName', line 2, position 19.'", "Details": null, "InnerError": null }

This is basically a limitation with the underlying .liquid library. So we might need to use workaround to replace the escape character as below.

Workaround: { "fullName": "{{content.FirstName | Escape | Replace: '"', '\"' | Append: ' ' | Append: content.LastName}}" }

Logic apps Service bus connector not honoring Maximum message count

Shashidharan Krishnan — Mon, 29 Jan 2018 11:49:57 GMT

You might come across a scenario where you dont receive the batch of messages configured under maximum message count property in your logic app service bus connector setting. In this example, i have configured the maximum message count as 20 but still I recieved only 1 or 2 messages every time even when i had a lot of messages in Service bus. The reason being my testqueue was partition enabled. Once i use the non partition queue, i was able to receive the configured number of messages in a single batch. The message count property specifies the maximum number of messages that can be returned. The actual number of messages returned can be anywhere between 0 to message count. The documentation of Service bus partitioning https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-partitioning also mentions this:

Browse/Peek messages: PeekBatch does not always return the number of messages specified in the MessageCount property. There are two common reasons for this. One reason is that the aggregated size of the collection of messages exceeds the maximum size of 256KB. Another reason is that if the queue or topic has the EnablePartitioning property set to true, a partition may not have enough messages to complete the requested number of messages.

Original Run Vs Resubmitted Run in Logic apps

Shashidharan Krishnan — Fri, 26 Jan 2018 17:29:38 GMT

In Logic app, you would often come across a scenario to differentiate between the original run and if the run is resubmitted via the Logic app portal(or Rest API) the Resubmitted Runs reuse Client Tracking ID of the Original Run, so they can be correlated. So IF RUNID= ClientTrackingID THEN Original RUN IF RUNID ≠ ClientTrackingID THEN Resubmitted RUN.

To differentiate in Portal

ORIGINAL RUN RESUBMITTED RUN 2. To Differenciate at Runtime You can get the ClientTrackingID using "@trigger().clientTrackingId" function and RunId using "@workflow().run.name" function "RUNID": {"inputs": "@workflow().run.name"

"ClientTrackingID": {"inputs": "@trigger().clientTrackingId",

ORIGINAL RUN

RESUBMITTED RUN

Logic App: Json serialization issue when receiving message from Service Bus

Shashidharan Krishnan — Thu, 21 Sep 2017 10:27:08 GMT

When parsing message received by logic App from Service, got the error “ InvalidJSON. The 'content' property of actions of type 'ParseJson' must be valid JSON. The provided value '@string3https://schemas.microsoft.com/2003/10/Serialization/�>{ "Field1": "Test1", "Field2": "Test2", "Field3": "Test3" }' cannot be parsed: 'Unexpected character encountered while parsing value: @. Path '', line 0, position 0.'.” We have the additional @string3https://schemas.microsoft.com/2003/10/Serialization/�> serialization information before my actual message content. Code used to send message to Service bus var connectionString = @"ConnectionString"; var queueName = "queuename"; var client = QueueClient.CreateFromConnectionString(connectionString, queueName); string jsonmsg = @"{ ""Field1"": ""Test1"", ""Field2"": ""Test2"", ""Field3"": ""Test3"" } var message = new BrokeredMessage(jsonmsg); client.Send(message); I am formatting the String datatype jsonmsg as a Brokered message sending it to Service bus. Instead I send the jsonmsg as a stream to the brokered, to resolve the above issue. var client = QueueClient.CreateFromConnectionString(connectionString, queueName); string jsonmsg = @"{ ""Field1"": ""Test1"", ""Field2"": ""Test2"", ""Field3"": ""Test3"" }"; byte[] bytes = Encoding.UTF8.GetBytes(jsonmsg); MemoryStream stream = new MemoryStream(bytes, writable: false); var msg = new BrokeredMessage(stream) ; client.Send(msg);

"MMC could not create the snap in" error for Biztalk Admin console

Shashidharan Krishnan — Wed, 13 Sep 2017 13:22:12 GMT

After in place upgrade of operating system on BizTalk Server, when i launch BizTalk admin console we got the error "MMC count not create the snap in" Resolution: Repair BizTalk Server from Add/Remove programs

MQSC related host instance fails after BizTalk Server restart

Shashidharan Krishnan — Tue, 12 Sep 2017 10:05:38 GMT

After restarting Biztalk Server, Host instances running MQSC adapter fails to start and the error message in the event viewer is "Could not load file or assembly 'Microsoft.BizTalk.Adapter.Mqsc.ImqWrapper.dll' or one of its dependencies. The network path was not found. A dependency could not be found. Refer to product documentation for information on MQSC Adapter software prerequisites." However once we manually start the host instance, the MQSC host instances runs fine. RESOLUTION: to resolve the issue, change the Biztalk host instance startup type from Automatic to Automatic (delayed Start)

xml resultset from SQL store procedure is splitt into multiple nodes in Logic Apps

Shashidharan Krishnan — Wed, 24 May 2017 08:00:33 GMT

I have a stored procedure which returns an XML result set. when I execute the stored procedure, the output is a single XML as below. CREATE PROCEDURE [dbo].[TESTSP] AS BEGIN SELECT * from testtable FOR XML AUTO END The output is a single xml object as below. But however when I execute the same in logic app, the xml was split into multiple nodes in json each with 2033 characters, as below. Output: "ResultSets": { "x": [ { "XML_F52E2B61-18A1-11d1-B105-00805F49916B": "" } ] } When you return XML from SQL Server, it does indeed split it into 2033-character chunks. There does not seem to be a way to control this behavior when returning raw XML as a result set. The solution here is to convert the output to NVARCHAR(MAX) before you do so. https://blogs.msdn.microsoft.com/sqlprogrammability/2006/04/13/what-does-server-side-for-xml-return/. “The chunk size is 2033 UCS-2 characters. Thus, XML larger than 2033 UCS-2 characters is sent to the client side in multiple rows each containing a chunk of the XML.“ The modified SP which fixes the issue, ALTER PROCEDURE [dbo].[TESTSP] AS BEGIN DECLARE @xml XML; SET @xml = (SELECT * from testtable FOR XML AUTO); SELECT CONVERT(NVARCHAR(MAX),@xml); END After which the output in Logic app is in single node as below. "body": { "OutputParameters": {},"ReturnCode": 0, "ResultSets": { "Table1": [ { "Column1": "" } ] } Further Reads : https://www.simple-talk.com/sql/learn-sql-server/using-the-for-xml-clause-to-return-query-results-as-xml/ https://www.simple-talk.com/sql/database-administration/converting-string-data-to-xml-and-xml-to-string-data/

Orchestration Subscription Throttling

Shashidharan Krishnan — Mon, 24 Apr 2017 15:30:12 GMT

One of the less heard features of orchestration throttling is Subscription Throttling. The Subscription based throttling will decide when to pause/resume the messages from moving to Subscribing orchestration instance based on the number waiting to be consumed. Recently I came across a scenario, where we had to utilize this functionality, but we don’t have a performance counter to check if we hit this condition or not. Like we use to figure out high memory or high database size or other throttling condition via perfmon counters. After collecting Microsoft internal Biztalk Traces(PSSDIAGforBiztalk), we found Line 6001: [1]0E10.1BDC::09/06/2016-10:34:05.244 [CSharp]:XLANG:Subscription.Delivered a message: instance: 1553b96b-bdbb-492d-8f48-649d06ad414f, msg: 392a204f-c859-4323-a9e4-fa090d6832e9 sub=280989aa-3eed-476f-b32f-f1c57b1ddceb Line 6039: [1]0E10.1BDC::09/06/2016-10:34:05.247 [CSharp]:XLANG:Subscription.Delivered a message: instance: 1553b96b-bdbb-492d-8f48-649d06ad414f, msg: 574e34be-9ada-41b9-bb01-4151ee8d2996 sub=280989aa-3eed-476f-b32f-f1c57b1ddceb Line 6078: [1]0E10.1BDC::09/06/2016-10:34:05.247 [CSharp]:XLANG:Subscription.Delivered a message: instance: 1553b96b-bdbb-492d-8f48-649d06ad414f, msg: 08822c2a-e179-4c79-8442-e03645c73fc7 sub=280989aa-3eed-476f-b32f-f1c57b1ddceb Line 6116: [1]0E10.1BDC::09/06/2016-10:34:05.247 [CSharp]:XLANG:Subscription.Delivered a message: instance: 1553b96b-bdbb-492d-8f48-649d06ad414f, msg: 96f85380-813f-4512-a04e-12bdbcf9f55c sub=280989aa-3eed-476f-b32f-f1c57b1ddceb Line 6154: [1]0E10.1BDC::09/06/2016-10:34:05.248 [CSharp]:XLANG:Subscription.Delivered a message: instance: 1553b96b-bdbb-492d-8f48-649d06ad414f, msg: 101c52c5-8b59-46c6-9b51-63f3d13fe3e9 sub=280989aa-3eed-476f-b32f-f1c57b1ddceb Line 6192: [1]0E10.1BDC::09/06/2016-10:34:05.248 [CSharp]:XLANG:Subscription.Delivered a message: instance: 1553b96b-bdbb-492d-8f48-649d06ad414f, msg: 2b77b798-a3c2-4c7e-92c1-fd3b65a86d19 sub=280989aa-3eed-476f-b32f-f1c57b1ddceb Line 6193: [1]0E10.1BDC::09/06/2016-10:34:05.248 [CSharp]:XLANG:Subscription.Deliver: suspending subscription 280989aa-3eed-476f-b32f-f1c57b1ddceb, instance 1553b96b-bdbb-492d-8f48-649d06ad414f Currently, I have set the value Pause/resume at 5:3. So when the sixth message arrived, the subscription was suspended and avoided messages to be sent to the actual orchestration instance. But you will still find the messages being refereeing in the orchestration instances( as you can not make it a suspended or subscription failure, on the subscription is paused) to check the subscription has throttled or not, you can check the Subscriptiontable(for Normal orchestration) or ConvoySetinstancetable(for Convoy Orchestration), first you will find fEnabled set to true and then the fpuased flag will be set to true, which will control the orchestration Subscription throttling. In my example I had Subscription pause at set to 5 and resume at set to 3, and could see the pause at value being modified when the message crossed 5, the paused value was 1 and when it reduced to 3, the pause at value changed to 0. After Resume value reached when the orchestration contains less than 3 messages This is not visible in admin console, as all the messages are in the same state because only the subscription is suspended or resumed. Hope this helps!! Happy BizTalking

Logic Apps : Blob name is null or empty

Shashidharan Krishnan — Mon, 05 Dec 2016 13:36:59 GMT

Recently when working with Azure blob Storage Action : Extract Archive to Folder I faced the error “Blob name is null or empty”. Host { "api": { "runtimeUrl": "https://logic-apis-westeurope.azure-apim.net/apim/azureblob" }, Method : post Path : /datasets/default/extractFolderV2 Queries: { "destination": "/testoutput", "source": "/test/shashiwebsite_201506011619.zip" } Output Body : { "status": 400, "message": "Blob name is null or empty.", "source": "127.0.0.1" } Solution: In the destination, we should also provide a prefix for the files extracted along with the destination folder name like. Source archive blob path : /test/shashiwebsite_201506011619.zip Destination folder path : /testoutput/testout Post which the files are extracted successfully and all the files are unzipped with the provided prefix.

BizTalk Receive Location crashes with the error “80131522”

Shashidharan Krishnan — Thu, 10 Mar 2016 08:56:00 GMT

When enabling BizTalk Receive location getting the error

"Event Type:
Error

Event Source:
BizTalk Server 2006

Event Category:
BizTalk Server 2006

Event ID: 5644

Computer: xyz

Description: The
Messaging Engine failed to add a receive location "rloc_abc" with URL
"C:\Test\In\*.*" to the adapter "FILE". Reason: "80131522”

Taking a process dump from the procdump, in the cmd prompt
we get the error types.

Exception: E06D7363.PEAVEETypeLoadException@@
Exception: E06D7363.msc
Exception: E06D7363.PEAVEETypeLoadException@@

Analysing dumps and the stack is something like below.

18
00000000`0131e920 00000000`03c44eeb BTSMsgCore!CMessageHelper::GetMessageFactory+0xf7

19 00000000`0131edb0 00000000`03c150f8 BTSMsgCore!CBTTransportProxy::GetMessageFactory+0x2cb

1a 00000000`0131ee80 00000000`03c16020 BTSMsgCore!CFileWatcher::InternalInit+0x6d8

1b 00000000`0131ef50 00000000`03c111c9 BTSMsgCore!CFileWatcher::Initialize+0x140

1c 00000000`0131ef80 00000000`03c91441 BTSMsgCore!CBTMFileListener::AddReceiveEndpoint+0x249

1d 00000000`0131f020 00000000`03c947b2 BTSMsgCore!CReceiverContainer::_AddReceiveEndpoint+0xc1

1e 00000000`0131f0b0 00000000`03c87332 BTSMsgCore!CReceiverContainer::AddReceiveEndpoint+0x2f2

1f 00000000`0131f240 00000000`03c8db57 BTSMsgCore!CReceiveManager::AddReceiver+0x602

20 00000000`0131f330 00000000`03c90744 BTSMsgCore!CReceiveManager::NotifyReceivers+0x9d7

21 00000000`0131f640 00000000`03c33b7d BTSMsgCore!CReceiveManager::Initialize+0x514

22 00000000`0131f6f0 00000000`03c43162 BTSMsgCore!CBTEndpointManager::InitializeEPM+0x67d

23 00000000`0131fae0 00000000`03c437b2 BTSMsgCore!CBTEndpointManager::InitializeAgent+0x652

24 00000000`0131fc20 00000000`00f88020 BTSMsgCore!CBTEndpointManager::Start+0x2f2

25 00000000`0131fc80 00000000`00f89e48 BTSPrcCntnr!CDBMultipleRowsetWalker::Attach+0x1f80

26 00000000`0131fce0 00000000`00f88245 BTSPrcCntnr!CDBMultipleRowsetWalker::Attach+0x3da8

27 00000000`0131fda0 00000000`01006645 BTSPrcCntnr!CDBMultipleRowsetWalker::Attach+0x21a5

28 00000000`0131fe10 00000000`010083ad BTSNTSvc64!CDBMultipleRowsetWalker::Attach+0x17c5

29 00000000`0131fe70 00000000`010086ee BTSNTSvc64!CDBMultipleRowsetWalker::Attach+0x352d

2a 00000000`0131ff10 000007ff`7fee4dc6 BTSNTSvc64!CDBMultipleRowsetWalker::Attach+0x386e

2b 00000000`0131ff50 00000000`77d6b8caadvapi32!ScSvcctrlThreadW+0x25

2c 00000000`0131ff80 00000000`00000000 kernel32!BaseThreadStart+0x3a

The exception is raised when loading GetMessageFactory class which is implemented in unmanaged library BTSMessageAgent.dll.

This CLSID is located in the registry:

HKEY_CLASSES_ROOT\CLSID\{6C90E0C2-4918-11d3-A242-00C04F60A533}

HKEY_CLASSES_ROOT\CLSID\{6C90E0C2-4918-11d3-A242-00C04F60A533}\InprocServer32

And the subkey InprocServer32 refers to the full path of the BTSMessageAgent.dll

BTSMessageAgent.dll is present in \Microsoft BizTalk Server 2013 R2\Bins64\BTSMessageAgent.dll.

In our case the dll was referring to incorrect path, in which BTSMessageAgent.dll was not present.

Corrected the registry key to point to right path and dll to resolve the issue.

Hope this helps.