Pages

Showing posts with label ErrorHandling. Show all posts
Showing posts with label ErrorHandling. Show all posts

Q & A: How To: Get rid of wcf one way port communication error

Friday, May 2, 2014
Q:

Hi,
 I Consumed one wcf one way serive at send port,but it is throwing error asking for reply.
A message sent to adapter "WCF-WSHttp" on send port "WcfCacheService" with URI "" is suspended.
Error details: System.ServiceModel.CommunicationException: The server did not provide a meaningful reply; this might be caused by a contract mismatch, a premature session shutdown or an internal server error.
Server stack trace:
at System.Runtime.AsyncResult.End[TAsyncResult](IAsyncResult result)
at System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.End(SendAsyncResult result)
at System.ServiceModel.Channels.ServiceChannel.EndCall(String action, Object[] outs, IAsyncResult result)
at System.ServiceModel.Channels.ServiceChannel.EndRequest(IAsyncResult result)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at System.ServiceModel.Channels.IRequestChannel.EndRequest(IAsyncResult result)
at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfClient`2.RequestCallback(IAsyncResult result)
MessageId: {BE03C2AD-5888-42AA-AE1B-D25965C6446A}

 Thanks,


Sol:

Hi,
Problem got solved finally....feel gr8..
In Binding tab of WCF-Custom adaptor...Binding Type is customBinding
in the bindings rightclick on CustomBindingElement->Add Extention->select one way->and move this to up other wise will get error,bcoz http transport should be last.
click ok and apply..thats it..
Regards,



Read more ...

BizTalk : How To : Trouble Shoot BAM EventBus Service Error in Event Log

Tuesday, April 9, 2013
post by Tiho

Here are 8 tables in each BizTalk Message Box database which store the tracking data before it is imported by the BAM EventBus Service (a.k.a. TDDS or Tracking Data Decoding Service) into the DTA/HAT and the BAM Primary Import databases. The tables are named TrackingData_x_y where 0 ≤ x ≤ 1 and 0 ≤ y ≤ 3. It is absolutely critical that the sizes of these tables do not increase over time. If the sizes are increasing than either TDDS is not able to catch up with the load or it is not working properly. There is a performance counter that can be used to monitor the size of the tracking data – BizTalk:Messsage Box:General Counters\Tracking Data Size.

The first step to troubleshoot issues with the tracking data is to examine the Windows Event Log on the BizTalk Tracking Host machine for errors from the BAM EventBus Service. Error information along with the serialized original tracking data might be available in the TDDS_FailedTrackingData tables in the DTA/HAT and the BAM Primary Import databases. Another place where error information might be available is the TDDS_Heartbeats table in the BizTalk Management database.

In this post I will focus on one very common cause which manifests as an error from the BAM EventBus Service in the Windows Event Log with event ID 25. 

The error should look like this:
Event Type: Error
Event Source: BAM EventBus Service
Event Category: None
Event ID: 25
Date: 12/20/2006
Time: 10:38:27 AM
User: N/A
Computer: TRACKINGHOST
Description:
Either another TDDS is processing the same data or there is an orphaned 
session in SQL server holding TDDS lock.Timeout expired. The timeout 
period elapsed prior to completion of the operation or the server is not 
responding. SQLServer: DBSERVER, Database: BAMPrimaryImport.

This error will usually show up every 5 minutes or so. Below are the steps to resolve it.
First, make sure that you are not hitting any of the issues described in this article. If this is the case, then killing the orphaned sessions or restarting the SQL Server machine will resolve the issue. You can use the information in this article to identify orphaned sessions.
If the issue is still there, then you most certainly have permissions problems. The account under which TDDS (and the BizTalk Tracking Host) is running must have execute permissions for the following stored procedures in the BizTalk Message Box database: TDDS_RedisterTDDSAccess and TDDS_GetNumTrackingPartitions. The same account must also have execute permissions for the TDDS_Lock stored procedure in the DTA/HAT and the BAM Primary Import databases.

The permissions are set correctly when BizTalk Server is first installed but might be altered later directly or indirectly by manually setting explicit deny permissions for the specific account or any group that it is a member of.
The best way to check that permissions are indeed the problem is to open Task Manager on the Tracking Host machine and on the Processes tab check the account under which the BTSNTSvc.exe process is running. This is the Tracking Host account. Now start SQL Query Analyzer or SQL Management Studio (or any of the command line counterparts) with the same user credentials as BTSNTSvc.exe. You can use the “runas” command or right-click on a shortcut and choose “Run as…”. I suggest that you do this test on the Tracking Host machine to rule out any network connectivity issues.
After you have connected to the correct SQL database execute the following:

In all BizTalk Message Box databases:

DECLARE @RC int
DECLARE @retVal int
EXEC @RC = [BizTalkMsgBoxDb].[dbo].[TDDS_RegisterTDDSAccess] @retVal OUTPUT 
SELECT @RC
GO

DECLARE @RC int
DECLARE @nPartitions tinyint
EXEC @RC = [BizTalkMsgBoxDb].[dbo].[TDDS_GetNumTrackingPartitions] @nPartitions OUTPUT 
SELECT @RC
GO

In the BizTalk DTA and BAM Primary Import databases:

DECLARE @RC int
DECLARE @resource nvarchar(128)
DECLARE @milisecTimeout int
DECLARE @retVal int
SELECT @resource = N'Foo'
SELECT @milisecTimeout = 5000
EXEC @RC = [BAMPrimaryImport].[dbo].[TDDS_Lock] @resource, @milisecTimeout, @retVal OUTPUT 
SELECT @retVal
SELECT @RC
GO

The results of these queries should be 0 and there should not be any errors. If you get “EXECUTE permission denied” errors then grant the corresponding execute permissions until you can execute the queries without any errors. At this point TDDS should start moving the tracking data from the Message Box databases to the DTA and the BAM databases.
Read more ...

BizTalk : Making Web / WCF service Call implementing Fault Exception Handling & Retry Mechanism

Thursday, December 27, 2012

This blog post contains some guidelines for consuming web services, with a focus on exception handling.  We will both handle pure messaging scenario and web service calls from within an orchestration.  I also make a distinguishment between asynchronous and synchronous flows.  Synchronous means that the flow needs to return a message to the original caller.  So in case of troubles, a SoapFault needs to be returned to the calling application.  In an asynchronous flow, you just need to make sure that your web service call is resumable.


Messaging Scenario – Asynchronous

When an error occurs during the web service call, the default behavior of BizTalk retry 3 times and will suspend the request message on the BizTalk Send Port and this instance will be resumable.  This is the perfect behavior for this asynchronous process.


Messaging Scenario - Synchronous

If you are in a synchronous process, a suspended Send Port will lead to a timeout on your Receive Port.  In this scenario you need to enable "Propagate Fault Message" on the Send Port and a SoapFault will be returned to the original caller.  Also think about the Retry Count and Retry Interval settings, because a bad configuration can also lead to timeouts.
image


Orchestration - Asynchronous

When you consume a web service from within an orchestration, it's getting more complex.  If the consumed web service throws an exception, BizTalk creates by default 2 suspended service instances.  Resuming them does not always have the expected behavior.

-  The Orchestration is suspended.  A resume will not change anything to the state of the Orchestration.
-  The Send Port is suspended.  A resume will resume the web service call as expected, but the Orchestration will not be able to continue processing afterwards.

image

How can we now achieve a resumable web service call?

First of all enable "Propagate Fault Message" on the Send Port.

Also modify the calling orchestration:
-  You need to create a loop.  This loop continues as long as the Boolean bSuccess equals false.
-  Modify the logical Orchestration Send Port and add a Fault Message.  To keep it general, you can choose the SoapFault (which is part of the Microsoft.BizTalk.GlobalPropertySchemas).
clip_image002        clip_image003
-  Add an exception handler to the web service call. Catch the Fault Message that was returned.  Add a suspend shape for human intervention. Note that it’s a good practice to also add an extra exception handler which catches a System.Exception.
-  If the web service call fails: set bSuccess == false in the exception handler.  If the call succeeds, set bSuccess == true, so the orchestration will exit the loop.

The result should look like this:
image

Now we've created a resumable web service call from within an orchestration.  When testing the orchestration in a failure scenario, you will see that there are still two suspended service instances:
-  The Orchestration is suspended.  This is the one that we've made resumable.
-  The Send Port is suspended.  To avoid this second service instance to be suspended, you can enable "Routing for Failed Messages".  This will generate an ErrorReport, instead of suspending the Send Port.  Subscribe on the ErrorReport with the filter ErrorReport.ErrorType == “FailedMessage”.

clip_image006


Orchestration - Synchronous

In this scenario, you will also need to catch the SoapFault (or other exception) and make sure that you don’t end up with suspended send port instances. See “Orchestration – Asynchronous”

The extra functionality that you’ll need to add is returning a SoapFault to the original caller.
- Add a Fault Message to the Request/Response receive port of your orchestration.
- You can choose to return a typed Fault or, to keep it general, a SoapFault (which is part of the Microsoft.BizTalk.GlobalPropertySchemas).
- Make sure you return the catched SoapFault (or the created SoapFault in case of other exception) in case of errors.
- Remark that you’ll need to add a decide shape to determine you’re in a success/failure scenario. Otherwise, the compiler will fail (complaining about unconstructed messages).

clip_image002[4]

Again, think about the Retry Count and Retry Interval settings on the send port.

post by Toon Vanhoutte
Read more ...
Tuesday, November 20, 2012

FIX Biztalk Error: 'Microsoft.XLANGs.BaseTypes.BPELExportable': inconsistent duplicate module attribute

While working on a solution we suddenly encountered the following error message while trying to build the code.
'Microsoft.XLANGs.BaseTypes.BPELExportable': inconsistent duplicate module attribute
It can be a nuisance to find the problem if you don't work with Biz Talk BPEL capabilities that often. It is however quite easy to fix. The error message is due to one orchestration having a different Module Exportable setting than the other orchestrations in the project. Making sure that the setting match between all orchestrations will make the error message disappear.


Read more ...

Advanced Users Biztalk WIKI : Useful How to Links Part - 5

Tuesday, June 12, 2012
 Useful How to Links Part - 5

Bre Static Support Key

Calling Data Access from Ado.Net

Sso Configuration Storing Values

Xml Document XPath Sample

ESB Dynamic Routing using Itineraries


Read more ...

Solution : Delimited Flat File Schema Misssing Fields At End

Friday, September 30, 2011
Q:
I have a Flat File Schema with records delimited by CRLF and fields delimited by a pipe symbol (|).  Occasionally we receive a record with some of the fields on the end of one record missing.  The file is not being processed correctly.  Since those fields are optional, I would like to be able to accept both type of file.
For example, a normal record might look like this:
TAG1|A1|B1|C1|D1
TAG2|A2|B2|C2|D2|E2|F2
TAG3|A3|B3|C3
But sometimes we get one like this (note that D2, E2, and F2 are missing):
TAG1|A1|B1|C1|D1
TAG2|A2|B2|C2
TAG3|A3|B3|C3
Is there any way that we can accommodate this requirement? I would like for both files to be processed.  The resulting xml should just have empty nodes for the missing fields.
Any help will be appreciated.

Sol:


Use the choice group node in your schema to achieve this. Create a choice group with option for fileds "C2|D2|E2|F2" and for "C2" only. Get more details about choice group from:
or
1) Set the "Allow Early Termination" property on the "schema" node of your flat file schema to "Yes".
2) Then set the "Min Occurs" property on all the fields which are optional to "0".
3) Validate your instance and have fun.

Regards
Read more ...

Handling Custom SOAP Exceptions in BizTalk

Monday, September 26, 2011
 Post by Romiko's Blog
Sometimes in Orchestrations you would like to throw a custom exception. Before we begin, remember this rule:
  • Never throw a general exception outside the catch block in an Orchestration
The rule above is a bit funny, because when you drag a default exception shape in a try block within an orchestration, it will default to General Exception and you cannot choose any other exception type.
Imagine we need to call a web service and then handle the response from it within an orchestration. However, sometimes I may get a timeout from the web service or I would only like to wait a 1 minute or so to get the response. What I usually do in these cases is create a listen shape after I have called the web service and then I use a delay shape to wait a specified amount of time for the web service response, if it does not respond within the time span , I simple throw a Timeout Exception.

However, as mentioned when you drag a default throw shape, the only option is to throw a general exception, to solve the problem, create a variable of type .NET Class
Then, navigate to the mscrolib library:
And choose the exception type as illustrated below.
Give the variable a friendly name in the Orchestration View
Add a throw exception under the Delay shape and assign the type of exception to the variable name you created (Weird I know, but this is how it is done)
Below are the properties of the Throw Exception Shape
As you can see above, I have a listen shape after sending a message to a web service and am now waiting for a response.
And you nearly done, what you then do is add a Catch Exception by right clicking the scope and clicking add exception handler:
  • Remember all transaction should be in a scope, so your catch blocks will automatically be appended to it. Now it is time to customize the catch block.
Right click the new Catch Block and set the type of exception to catch, in my case, a timeout exception.
There are two properties to set here:
  • Exception Object Type
  • Exception Object Name
In my case this will be
Exception Object Type = System.TimeoutException (I had to choose .NET Class and navigate through the mscrolib again)
Exception Object Name = e ( I chose e, as this is what we use in coding most of the time, you can choose anything you like)
So the Exception Object Name is similar to doing this:
catch (Exception ex)
{
}
This is how looks is now.

Don't forget to add custom code to handle the exception in the Catch Block, maybe to update a log table or send a message somewhere, like I have done above, so now when a web service times out, the orchestration will throw a timeout exception, this is much more intuitive than seeing a general exception!

SOAP exceptions from a web service

In order to catch soap exception from a web service, what you do is add a reference to the BizTalk project for:
System.Web.Services

Then add an exception handle block:


You can then access the information of the exception message like this:
e.Message
e.g.

Or you can create a Soap Exception message and send it to the message box for failure routing, here is an example from:
Source: Saravana Kumar, http://www.digitaldeposit.net/blog/2007/05/orchestration-handle-soap-exception-and.html

A word of warning, if a web service throws a soap exception, the port will retry by default 3 times at intervals of 5 minutes, I changed the retry here to 0 for my example, so that the soap exception is caught and a log in made in SQL, however if you using a delay shape make sure the amount in the delay is greater than the total interval in the send point, else you will never catch the soap exception and will just catch timeout exceptions!
So below, works fine with a delays of 2.5 minutes, however if I made retry count = 1, then the delay should be greater than 5 minutes! You can really get confused when a soap exception occurs and the orchestration does not catch it, it will only catch it after the retry count is done in the send port of the web service!

Here is the exception in SQL
Summary:
  1. Create a VARIABLE in the orchestration view of the exception type you want to catch, use mscorlib to assign the variable type to an exception
  2. Drag a throw shape and set the type of exception to throw to the variable name (yes it is automatically instantiated)
  3. Add a custom Catch block to the SCOPE where the throw shape is located and once again, set the properties of Exception Object Name and Exception Object Type, where type will come from mscorlib and name is anything you like!
Read more ...

Handling of Exceptions in One Way Web Services in BizTalk

Monday, September 26, 2011
post by Richard Seroter
I’m currently working on the design of the “fan out” process from our ERP system (SAP) and we’ve had lots of discussions around asynchronous services and exception handling.
The pattern we’ve started with is that BizTalk receives the message from SAP and fans it out using one-way send ports (and web services) to each interested subscriber. However, some folks have expressed concern about how exceptions within the various services get handled. In a true one-way architecture, BizTalk is never alerted that the service failed, and the service owner is responsible for gracefully handling all exceptions.
If a .NET developer builds a very plain web service, their web method may be something like this:
[WebMethod]
public void DoSomethingCool(CoolObject co) {
   throw new Exception(“bad moon rising”);
}
So what does this actually generate? If you look, the actual contract generated from this yields a response message!
You can see there that the service caller would expect a confirmation message back. If BizTalk calls this service, even from a one-way send port, it will wait for this response message. For the service above that fails, BizTalk shows the following result:
The proper way (as opposed to the lazy way above) to build a one-way .NET web service is to add the attribute tag below.
[SoapDocumentMethod(OneWay = true)]
[WebMethod]
public void DoSomethingCool(CoolObject co) {
   throw new Exception(“bad moon rising”);
}
If you build THIS service, then the contract looks like this …
Notice that the only response BizTalk (or any caller) is expecting is a HTTP 200 response. If anything besides the base connection fails, BizTalk won’t know or care. If I call the service now, there is no indication (Event Log, Suspended Messages) that anything went wrong.
The first web service above is the equivalent of writing the web method as such …
[SoapDocumentMethod(OneWay = false)]
[WebMethod]
public void DoSomethingCool(CoolObject co) {
   throw new Exception(“bad moon rising”);
}
Setting OneWay=false would force this method to return a response message. So what does this response message REALLY look like? I traced the web service call, and indeed, you get a DoSomethingCoolResponse message that is apparently just eaten up by BizTalk (no need to subscribe to the response) …
Now what if the web service times out on these “fake” one way calls? Would BizTalk really raise an error, or would it simply say “ok, I sent it, never got a response, but that’s cool.” I added a 2 minute “sleep” to my service and tried it out. Sure enough, BizTalk DID suspend the message (or set it for retry, depending on your settings).
The only exception that will cause either a two-way OR one-way service to suspend is if the connection fails. If I shut down the web server, calling either type of service results in a suspended (or retry) message like so …
While it’s super that a service that returns no data can still return a basic success acknowledgement, there are broad implications that need to be thought out. Do you really want BizTalk to catch an exception thrown by your service? If the code is bad, all the retries are going to fail anyway. What about keeping messages in order? Do you really want to use “ordered delivery” and thus block all messages following the “bad” service call? I’m a bigger fan of letting the service itself catch the exception, log the ID of the object coming in, and on a scheduled basis, go retrieve the actual data from the system of record, vs. trying to make BizTalk keep things all synchronized.
Any architecture experiences with one-way services or patterns you wish to share?
Read more ...