Compartir a través de


BizTalk Accelerator for RosettaNet (BTARN) - continued

Troubleshooting BTARN Web Pages

One of the more frustrating things about working with BTARN is troubleshooting the web pages. The code causes the error event log entry to be either 400 or 500. The actual error is lost.

private void HandleError(ErrorLevel level, Exception failure)

{

ExceptionManager.Publish(failure,3001, ExceptionManager.CategoryIdentifier.RNIFSenderWebApplication);

   switch(level)

   {

      case ErrorLevel.ParamValidationFailure:

      case ErrorLevel.UnknownFailure:

         System.Diagnostics.EventLog.WriteEntry("BARN", "400 From Page", System.Diagnostics.EventLogEntryType.Information);

         Response.StatusCode = 400;

         break;

      case ErrorLevel.ProxyToOuterFailure:

         System.Diagnostics.EventLog.WriteEntry("BARN", "500 From Page", System.Diagnostics.EventLogEntryType.Information);

         Response.StatusCode = 500;

         break;

      default:

         // status code must have already been set

         break;

   }

}

Equally frustrating is the lack of a debugging switch in the code. The only option is to do this yourself. The BTARN SDK folder provides the web application code. Strategically adding lines of code like the following can be helpful.

 

System.Diagnostics.EventLog.WriteEntry("BARN", "Load In", System.Diagnostics.EventLogEntryType.Information);

 

Place these statements throughout the page for testing. Change the second parameter to indicate what part of the code executed.

Also it is a good idea to write out any http errors from the post. Locate the ProxyToOuterRequest method. Wrap:

 

outerRequestReqStm = outerRequest.GetRequestStream();

 

with a catch block.

try

{

   outerRequestReqStm = outerRequest.GetRequestStream();

}

catch (WebException ex)

{

   System.Diagnostics.EventLog.WriteEntry("BTARN", ex.Status.ToString(), System.Diagnostics.EventLogEntryType.Information);

   System.Diagnostics.EventLog.WriteEntry("BTARN", ex.Message, System.Diagnostics.EventLogEntryType.Information);

   System.Diagnostics.EventLog.WriteEntry("BTARN", outerRequest.RequestUri.ToString(), System.Diagnostics.EventLogEntryType.Information);

   throw ex;

}

This is an ideal time to add code to output the message. Place the following code in the load method.

 

Request.SaveAs(@"c:\io\"+System.Guid.NewGuid().ToString()+".txt",false);

 

Don't forget to change the save location to a valid value.

Adding the code and deploying is not very difficult if this was all there is to it. Not so fast, this is BTARN. Backup the default virtual site by copying it to a safe location. Then for any version of BTARN after 3.0 download the hot fix from KB933500.

This change is required by Visual Studio. The hot fix provides detailed code changes so the pages will compile with the newer versions. Once completed deploy the new dll's per the text file provided with hot fix. The text file also contains a dated link. The correct link is:

https://msdn.microsoft.com/en-us/library/aa479568.aspx

It is not necessary to make the changes to the send and receive pages. The design allows separate deployment. It makes sense to do both pages for future use. After the changes the new dll's can be copied in. Operate BTARN and analyze the application event log to understand where the process is failing.

Once the problem has been resolved simply copy your shiny new troubleshooting virtual folder to a safe location and restore the original virtual folder.

These changes are intended for troubleshooting. If custom pages are intended to be a permanent part of the environment keep the original virtual folder. This will be required for Microsoft product group support. Any problem will need to be reproduced using the original code.