Known issues with BizTalk Server 2020 RosettaNet accelerator (Part 2)

Microsoft

This is the second part of the previous RosettaNet post: Known issues with BizTalk Server 2020 RosettaNet accelerator (Part 1) 

 

Below are some other issues we may meet while setting up BTARN Double Action scenario on BizTalk 2020.

 

Steps:

 

1.Some similar WCF-SQL bindings need to be manually corrected for DoubleAction as the following.

 

MessagesToLOB_Receive_Location:

 

WenJun_Zhang_0-1586507275548.png

 

WenJun_Zhang_1-1586507275557.png

 

WenJun_Zhang_2-1586507275562.png

 

Microsoft.Solutions.BTARN.SDK.DoubleAction orchestration:

 

WenJun_Zhang_3-1586507275564.png

 

2.After that, if you submit some test 3A4 PO document, at the receiver side, you may find the DoubleAction orchestration failed at the following ActoinMessage expression shape.

 

WenJun_Zhang_4-1586507357451.png

 

WenJun_Zhang_5-1586507357458.png

 

The detailed error is:

 

xlang/s engine event log entry: Uncaught exception (see the 'inner exception' below) has suspended an instance of service 'Microsoft.Solutions.BTARN.SDK.DoubleAction(3870c2de-1d7f-2477-b3b1-dd5740090e72)'.

The service instance will remain suspended until administratively resumed or terminated.

If resumed the instance will continue from its last persisted state and may re-throw the same unexpected exception.

InstanceId: e8594d5f-391f-4aaa-b69a-eb014cf12d80

Shape name: ConstructServiceContent

ShapeId: 74fe76a6-31d1-4e52-9973-60890674bb23

Exception thrown from: segment 1, progress 7

Inner exception: There is no value associated with the property 'Doubleaction.PropertySchema.PIPCode' in the message.

       

Exception type: MissingPropertyException

Source: Microsoft.XLANGs.BizTalk.Engine

Target Site: System.Object GetPropertyValueThrows(System.Type)

The following is a stack trace that identifies the location where the exception occured

 

   at Microsoft.BizTalk.XLANGs.BTXEngine.BTXMessage.GetPropertyValueThrows(Type propType)

   at Microsoft.Solutions.BTARN.SDK.DoubleAction.segment1(StopConditions stopOn)

   at Microsoft.XLANGs.Core.SegmentScheduler.RunASegment(Segment s, StopConditions stopCond, Exception& exp)

 

I spent some time on diagnostic and found the problem is on Schema validation.

Wcf-SQL XmlPolling will add an extra blank namespace to the parent node(i.e: MessagesToLOB).

 

WenJun_Zhang_6-1586507406511.png

 

So if we manually validate the schema in VS, the following error will be returned:

 

Invoking component...

C:\Users\Administrator\Desktop\{8E72275D-C59C-4976-8066-91116FA1C8C7}_{4C659FCB-8DA4-4E58-9DEE-D88896B54D8D}_body.xml: error BEC2004: The element 'CustomSchema' in namespace 'http://DoubleAction.CustomSchema' has invalid child element 'MessagesToLOB'. List of possible elements expected: 'MessagesToLOB' in namespace 'http://DoubleAction.CustomSchema'.

C:\Program Files (x86)\Microsoft BizTalk Accelerator for RosettaNet\SDK\PipAutomation\DoubleAction\MessageFromLOBSchema.xsd: error BEC2004: Validate Instance failed for schema MessageFromLOBSchema.xsd, file: <file:///C:\Users\Administrator\Desktop\{8E72275D-C59C-4976-8066-91116FA1C8C7}_{4C659FCB-8DA4-4E58-9DEE-D88896B54D8D}_body.xml>.

Component invocation succeeded.

 

The simplest solution is to modify PipAutomationGetAction stored procedure and add a default namespace to the output parent node MessagesToLOB.

 

ALTER PROCEDURE [dbo].[PipAutomationGetAction]

AS

BEGIN TRANSACTION

DECLARE @tempGUID nvarchar(36)

SELECT TOP 1 @tempGUID = MessageID FROM MessagesToLOB

   WHERE Delivered = 0 AND MessageCategory = 10

  ORDER BY TimeCreated ;

 

WITH XMLNAMESPACES (DEFAULT 'http://DoubleAction.CustomSchema') 

  SELECT PIPInstanceID,DestinationPartyName,SourcePartyName,PIPCode,PIPVersion,ServiceContent FROM MessagesToLOB

   WHERE MessageID = @tempGUID

For xml auto

 

UPDATE MessagesToLOB SET Delivered = 1 WHERE MessageID = @tempGUID

COMMIT TRANSACTION

 

3. You may also find some 413 and 403.7 errors in IIS log.

 

#Software: Microsoft Internet Information Services 10.0

#Version: 1.0

#Date: 2020-03-30 19:44:27

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken

2020-03-30 19:44:27 10.157.18.54 POST /BTARNApp/RNIFReceive.aspx - 443 - 10.157.18.193 - - 413 0 0 82

#Software: Microsoft Internet Information Services 10.0

#Version: 1.0

#Date: 2020-03-30 19:49:36

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken

2020-03-30 19:49:36 10.157.18.54 POST /BTARNApp/RNIFReceive.aspx - 443 - 10.157.18.193 - - 403 7 5 102

2020-03-30 19:49:46 10.157.18.54 POST /BTARNApp/RNIFReceive.aspx - 443 - 10.157.18.193 - - 403 7 5 10

 

In this case, you will need to increase uploadReadAheadSize and maxRequestEntityAllowed as well as disable client certificate setting.

 

WenJun_Zhang_0-1586510820968.png

 

If all the errors are fixed and bindings are corrected, we should be able to find the corresponding 3A4 PO and PO confirmation records in MessagesFromLOB and MessagesToLOB tables of receiver and sender’s BTARNDATA DB.

 

Sender:

 

WenJun_Zhang_7-1586507444177.png

 

Receiver:

 

WenJun_Zhang_8-1586507444215.png

 

0 Replies