What's up Chewy?

Updates from October, 2005 Toggle Comment Threads | Keyboard Shortcuts

• 

  Chewy Chong 2:48 am on October 18, 2005 Permalink | Reply  

  The Little Known "Console" Remote Desktop (RDP) Connection… 

  Sooner or later in every development environment you will hear…

   

  “Who the @*!# is tying up all the connections to the server.  Get off it!  I need to (do a build / perform a test / debug this or that)”

   

  Most people know there are two remote desktop (RDP) connections for use on a server for administration purposes.  However, many people don’t know about the secret ‘third’ RDP connection.  This connection is called the ‘console’ connection.  As the name implies, the console connection is a RDP connection to the server’s physical console.  In other words, you can see what the guy standing at the server sees. 

   

  This is good for:

   

  -          Always being able to get a RDP connection to a server as this connection will kick off any existing console connection (the guy standing at the server will either be forcibly logged off or his screen will be locked).  This is a quick fix when you need a RDP connection but the existing two virtual RDP connections are tied up.

  -         Remotely working with applications that have issues functioning in a virtual RDP connection.  Some apps write directly to the console and if you’re in a virtual connection, you won’t see the message and think the app has locked up.  This happens a lot with application installations over RDP so if you’re attempting to install an app and it just stops… try using the console.

   

  To use this:

   

  Start > Run > mstsc /console /v:name-of-the-server

   

  This instructs the remote desktop application (mstsc.exe) to connect to the console session instead of a virtual one.

   

  Btw:  I am not sure if the technical terminology is 100% correct so feel free to correct me if necessary.

   

   

  Reply Cancel reply

  Required fields are marked *

  Name *

  Email *

  Website

  

  Notify me of follow-up comments via email.

  Notify me of site updates

• 

  Chewy Chong 3:39 am on October 13, 2005 Permalink | Reply  

  BizTalk File Adapter Macros (the stuff that goes in %these_things%) 

  I can never remember all the different macros for the BizTalk file adapter.  On the project, I’m having to write out messages as part of our debugging process.  Instead of the standard file adapter generated file names:

  {1F34F960-03D6-4CA0-B311-EB9C6F5D111C}.xml

  I would rather have something I can set within the orchestration depending on the message being processed:

  ProcessedApp-ChewyC-12Oct1820.xml

  The macros supported by the BizTalk file adapter is shown below.  The macro that allows me to set the message’s file name is %SourceFileName% (case sensitive).  You can set this value within the orchestration via

  TheBiztalkMessage(FILE.ReceivedFileName) = “TheNameOfTheFile”

  Just an additional note, you need to do the above in a BizTalk “construct message” shape for the target message.

  Macro name	Substitute value
  %datetime%	Coordinated Universal Time (UTC) date time in the format YYYY-MM-DDThhmmss (for example, 1997-07-12T103508).
  %datetime_bts2000%	UTC date time in the format YYYYMMDDhhmmsss, where sss means seconds and milliseconds (for example, 199707121035234 means 1997/07/12, 10:35:23 and 400 milliseconds).
  %datetime.tz%	Local date time plus time zone from GMT in the format YYYY-MM-DDThhmmssTZD, (for example, 1997-07-12T103508+800).
  %DestinationParty%	Name of the destination party. The value comes from message the context property BTS.DestinationParty.
  %DestinationPartyID%	Identifier of the destination party (GUID). The value comes from the message context property BTS.DestinationPartyID.
  %DestinationPartyQualifier%	Qualifier of the destination party. The value comes from the message context property BTS.DestinationPartyQualifier.
  %MessageID%	Globally unique identifier (GUID) of the message in BizTalk Server. The value comes directly from the message context property BTS.MessageID.
  %SourceFileName%	Name of the file from where the File adapter read the message. The file name includes extension and excludes the file path, for example, foo.xml. When substituting this property, the File adapter extracts the file name from the absolute file path stored in the FILE.ReceivedFileName context property. If the context property does not have a value, for example, if message was received on an adapter other than File adapter, then the macro will not be substituted and will remain in the file name as is (for example, C:\Drop\%SourceFileName%).
  %SourceParty%	Name of the source party from which the File adapter received the message.
  %SourcePartyID%	Identifier of the source party (GUID). The value comes from the message context property BTS.SourcePartyID.
  %SourcePartyQualifier%	Qualifier of the source party from which the File adapter received the message.
  %time%	UTC time in the format hhmmss.
  %time.tz%	Local time plus time zone from GMT in the format hhmmssTZD (for example, 124525+530).

  (Blatantly stolen from Jan Tielens’ Blog -great blog to read for BizTalk goodies: http://weblogs.asp.net/jan/archive/2004/03/19/92701.aspx)
  

   
• 

  Chewy Chong 4:56 am on October 9, 2005 Permalink | Reply  

  The Ever-Helpful BizTalk “System.Runtime.InteropServices.COMException” Error 

   

  I have had this question pop up so many times with the dev team here that it warranted a blog posting (quite a feat considering there has been a blogging dry spell since my return from TechEd).

   

  The Situation:  Orchestration returning XML message through a web service but the message does not quite make it.  The helpful error was:

   

  The “SOAP” adapter is suspending an outbound message going to destination URL:”/Wapol/Services.asmx”. Details:”Exception of type System.Runtime.InteropServices.COMException was thrown.”.

   

  The Cause:  The XML message contains something that fails validation (in our case, a datetime value where a date value was expected).  The web service picks up the exception but is not configured to pass the exception details… hence the COMException. 

   

  The Fix:  Modify the web service’s web.config ThrowDetailError to true.  This way you can get something more meaningful.

   

  We did notice this was not perfect.  The eventlog and HAT will still show COMException but the results returned from the web service should provide the yummy error details .