Coding

NullReferenceException when calling the Retrieve method of the OrganizationServiceProxy object

Geordie — Thu, 01 Sep 2011 13:32:10 GMT

I have recently started to update a very successful SAP CRM integration I originally built 5 or 6 years ago. We have recently started the implementation of CRM 2011 so the business has decided to take the opportunity to change the data that they want to synchronize between the 2 systems. Luckily the integration is both modular and to a large degree dynamic. The core logic should remain relatively untouched and only the SAP and CRM connection dlls should need any real work.

The changes to the SAP connector were simple and took a matter of a couple of hours. Partially because I still have the virtual development machine I used to create the SAP proxy code.

The Crm connector has been a differnent story. There have been a number of changes to the CRM services since CRM 3. So like all developers I start exploring and testing the old and new ways to communicate with CRM. To that end I created a test project and started by creating a reference to the new CRM service (http://ServerName/OrgName/XRMServices/2011/Organization.svc) . The first method call to retrieve an account worked without any issues.

private CrmService.OrganizationServiceClient service = new CrmService.OrganizationServiceClient();

private void GetAccount_Click(object sender, EventArgs e)
{
   QueryExpression query = new QueryExpression("account");
   ConditionExpression condition1 = new ConditionExpression();

   condition1.AttributeName = "accountnumber";
   condition1.Operator = ConditionOperator.Equal;
   condition1.Values.Add("5500");

   // Build the filter based on the conditions.
   FilterExpression filter = new FilterExpression();
   filter.FilterOperator = LogicalOperator.And;
   filter.Conditions.Add(condition1);

   // Set the Criteria field.
   query.Criteria.AddFilter(filter);

   query.ColumnSet.AllColumns = true;
   ColumnSet columns = new ColumnSet();
   columns.AllColumns = true;
   Entity accnt = service.RetrieveMultiple(query)[0];
}

I then explored the options around early binding and wrote the following method based on a MSDN article (http://msdn.microsoft.com/en-us/library/gg334754.aspx).

private void btnEarlyBinding_Click(object sender, EventArgs e)
{
   OrganizationServiceProxy serviceProxy;
  IOrganizationService orgService;

   Uri orgUri = new Uri(@"http://ServerName/OrgName/XRMServices/2011/Organization.svc");

   ClientCredentials credentials = new ClientCredentials();
   credentials.Windows.ClientCredential = new System.Net.NetworkCredential("CrmAdministrator", "XXXXX", "domain");

   serviceProxy = new OrganizationServiceProxy(orgUri, null, credentials, null);

   // This statement is required to enable early-bound type support.
   serviceProxy.ServiceConfiguration.CurrentServiceEndpoint.Behaviors.Add(new ProxyTypesBehavior());
   orgService = (IOrganizationService)serviceProxy;

   Guid guid = new Guid("f02b9ae2-1aab-db11-964f-000cf15bffae");
   ColumnSet columns = new ColumnSet();
   columns.AllColumns = true;
   object acc = (Account)orgService.Retrieve("account", guid, columns);
}

When this code ran it caused a Null Reference Exception when calling the Retrieve method of the OrganizationServiceProxy object.

I was not able to determine the cause of this problem and there are other options so I continued to test code against the CRM service reference. Unfortunately I hit another issue. My code as mentioned is dynamic and uses reflection to identify the attribute types and update attribute values. Unfortunately with the new CRM service only populated CRM attributes are returned and reflection gives you a null reference error. I was then directed to look at the Metadata service. To my disappointment that resulted in an Invalid Operation Exception - 'Collection was modified; enumeration operation may not execute.' on calling the Execute method on the OrganizationServiceProxy object. See http://social.microsoft.com/Forums/en-US/crmdevelopment/thread/10273be7-22ec-4724-874f-a8f6bd133455 for more info on this issue.

At this point I started to doubt the stability of the environment and started to look for way to isolate the problem. I started to look at the SDK and opened one of the packaged solutions. To my surprise it worked fine. I copied the code that was failing to the SDK project and it also worked. So the code is fine so what is the problem??

I need to know the cause so started comparing all the different characteristics of the 2 projects. As soon as I removed the service reference to the CRM services the early binding code started to work.

When I added it back in I started to get exceptions again.

Hope this helps someone.

Geordie

Conversion of BizTalk Projects to Use the New WCF-SAP Adaptor

Geordie — Sun, 06 Feb 2011 18:45:03 GMT

We are in the process of upgrading our BizTalk Environment from BizTalk 2006 R2 to BizTalk 2010. The SAP adaptor in BizTalk 2010 is an all new and more powerful WCF-SAP adaptor. When my colleagues tested out the new adaptor they discovered that the format of the data extracted from SAP was not identical to the old adaptor. This is not a big deal if the structure of the messages from SAP is simple. In this case we were receiving the delivery and invoice iDocs. Both these structures are complex especially the delivery document. Over the past few years I have tweaked the delivery mapping to remove bugs from original mapping. The idea of redoing these maps did not appeal and due to the current work load was not even an option. I opted for a rather crude alternative of pulling in the iDoc in the new typed format and then adding a static map at the start of the orchestration to convert the data to the old schema.

Note WCF-SAP data formats (on the binding tab of the configuration dialog box is the ‘RecieiveIdocFormat’ field):

Typed: Returns a XML document with the hierarchy represented in XML and all fields being represented by XML tags.
RFC: Returns an XML document with the hierarchy represented in XML but the iDoc lines in flat file format.
String: This returns the iDoc in a format that is closest to the original flat file format but is still wrapped with some top level XML tags. The files also contained some strange characters at the end of each line.

I started with the invoice document and it was quite straight forward to add the mapping but this is where my problems started. The orchestrations for these documents are dynamic and so require the identity of the partner to be able to correctly configure the orchestration. The partner identity is in the EDI_DC40 segment of the iDoc. In the old project the RECPRN node of the segment was promoted. The code to set a variable to the partner ID was now failing. After lot of head scratching I discovered the problem was due to the addition of Namespaces to the fields in the EDI_DC40 segment. To overcome this I needed to use an xPath query with a Namespace Manager. This had to be done in custom code.

I now tried to repeat the process with the delivery document. Unfortunately when we tried to get sample typed data from SAP an exception was thrown.

The adapter "WCF-SAP" raised an error message. Details "Microsoft.ServiceModel.Channels.Common.XmlReaderGenerationException: The segment or group definition E2EDKA1001 was not found in the IDoc metadata. The UniqueId of the IDoc type is: IDOCTYP/3/DESADV01/ZASNEXT1/640. For Receive operations, the SAP adapter does not support unreleased segments.

Our guess is that when the WCF-SAP adaptor tries to down load the data it retrieves a data schema from SAP. For some reason the schema does not match the data. This may be due to the version of SAP we are running or due to a customization. Either way resolving this problem did not look easy.

When doing some research on this problem I found an article showing me how to get the data from SAP using the WCF-SAP adaptor without any XML tags.

http://blogs.msdn.com/b/adapters/archive/2007/10/05/receiving-idocs-getting-the-raw-idoc-data.aspx

Reproduction of Mustansir blog:

Since the WCF based SAP Adapter is ... well, WCF based, all data flowing in and out of the adapter is encapsulated within a SOAP message. Which means there are those pesky xml tags all over the place. If you want to receive an Idoc from SAP, you can receive it in "Typed" format (in which case each column in each segment of the idoc appears within its own xml tag), or you can receive it in "String" format (in which case there are just 2 xml tags at the top, the raw xml data in string/flat file format, and the 2 closing xml tags).

In "String" format, an incoming idoc (for ORDERS05, containing 5 data records) would look like:

<ReceiveIdoc xmlns='http://Microsoft.LobServices.Sap/2007/03/Idoc/'><idocData>EDI_DC40 8000000000001064985620 E2EDK01005 800000000000106498500000100000001 E2EDK14 8000000000001064985000002000000020111000 E2EDK14 8000000000001064985000003000000020081000 E2EDK14 80000000000010649850000040000000200710 E2EDK14 80000000000010649850000050000000200600</idocData></ReceiveIdoc>

(I have trimmed part of the control record so that it fits cleanly here on one line).

Now, you're only interested in the IDOC data, and don't care much for the XML tags. It isn't that difficult to write your own pipeline component, or even some logic in the orchestration to remove the tags, right? Well, you don't need to write any extra code at all - the WCF Adapter can help you here!

During the configuration of your one-way Receive Location using WCF-Custom, navigate to the Messages tab. Under the section "Inbound BizTalk Messge Body", select the "Path" radio button, and:

(a) Enter the body path expression as: /*[local-name()='ReceiveIdoc']/*[local-name()='idocData']

(b) Choose "String" for the Node Encoding.

What we've done is, used an XPATH to pull out the value of the "idocData" node from the XML. Your Receive Location will now emit text containing only the idoc data.

You can at this point, for example, put the Flat File Pipeline component to convert the flat text into a different xml format based on some other schema you already have, and receive your version of the xml formatted message in your orchestration.

This was potentially a much easier solution than adding the static maps to the orchestrations and overcame the issue with ‘Typed’ delivery documents. Not quite so fast…

Note: When I followed Mustansir’s blog the characters at the end of each line disappeared.

After configuring the adaptor and passing the iDoc data into the original flat file receive pipelines I was receiving exceptions.

There was a failure executing the receive pipeline: "PAPINETPipelines.DeliveryFlatFileReceive, CustomerIntegration2.PAPINET.Pipelines, Version=1.0.0.0, Culture=neutral, PublicKeyToken=4ca3635fbf092bbb" Source: "Pipeline " Receive Port: "recSAP_Delivery" URI: "D:\CustomerIntegration2\SAP\Delivery\*.xml" Reason: An error occurred when parsing the incoming document: "Unexpected data found while looking for:

'Z2EDPZ7'

The current definition being parsed is E2EDP07GRP. The stream offset where the error occured is 8859. The line number where the error occured is 23. The column where the error occured is 0.".

Although the new flat file looked the same as the old one there was a differences. In the original file all lines in the document were exactly 1064 character long. In the new file all lines were truncated to the last alphanumeric character.

The final piece of the puzzle was to add a custom pipeline component to pad all the lines to 1064 characters. This component was added to the decode node of the custom delivery and invoice flat file disassembler pipelines.

Execute method of the custom pipeline component:

public IBaseMessage Execute(IPipelineContext pc, IBaseMessage inmsg)

{

//Convert Stream to a string

Stream s = null;

IBaseMessagePart bodyPart = inmsg.BodyPart;

// NOTE inmsg.BodyPart.Data is implemented only as a setter in the http adapter API and a

//getter and setter for the file adapter. Use GetOriginalDataStream to get data instead.

if (bodyPart != null)

s = bodyPart.GetOriginalDataStream();

string newMsg = string.Empty;

string strLine;

try

{

StreamReader sr = new StreamReader(s);

strLine = sr.ReadLine();

while (strLine != null)

{

//Execute padding code

if (strLine != null)

strLine = strLine.PadRight(1064, ' ') + "\r\n";

newMsg += strLine;

strLine = sr.ReadLine();

}

sr.Close();

}

catch (IOException ex)

{

throw new Exception("Error occured trying to pad the message to 1064 charactors");

}

//Convert back to stream and set to Data property

inmsg.BodyPart.Data = new MemoryStream(Encoding.UTF8.GetBytes(newMsg)); ;

//reset the position of the stream to zero

inmsg.BodyPart.Data.Position = 0;

return inmsg;

}

Click Once Deployment Process and Issue Resolution

Geordie — Thu, 18 Mar 2010 18:47:11 GMT

Introduction
We are adopting Click Once as a deployment standard for Thick .Net application clients. The latest version of this tool has matured it to a point where it can be used in an enterprise environment. This guide will identify how to use Click Once deployment and promote code trough the dev, test and production environments.
Why Use Click Once over SCCM
If we already use SCCM why add Click Once to the deployment options. The advantages of Click Once are their ability to update the code in a single location and have the update flow automatically down to the user community. There have been challenges in the past with getting configuration updates to download but these can now be achieved. With SCCM you can do the same thing but it then needs to be packages and pushed out to users. Each time a new user is added to an application, time needs to be spent by an administrator, to push out any required application packages. With Click Once the user would go to a web link and the application and pre requisites will automatically get installed.
New Deployment Steps Overview
The deployment in an enterprise environment includes several steps as the solution moves through the development life cycle before being released into production. To make mitigate risk during the release phase, it is important to ensure the solution is not deployed directly into production from the development tools. Although this is the easiest path, it can introduce untested code into production and result in unexpected results.
1. Deploy the client application to a development web server using Visual Studio 2008 Click Once deployment tools. Once potential production versions of the solution are being generated, ensure the production install URL is specified when deploying code from Visual Studio. (For details see ‘Deploying Click Once Code from Visual Studio’)

2. xCopy the code to the test server. Run the MageUI tool to update the URLs, signing and version numbers to match the test server. (For details see ‘Moving Click Once Code to a new Server without using Visual Studio’)

3. xCopy the code to the production server. Run the MageUI tool to update the URLs, signing and version numbers to match the production server. The certificate used to sign the code should be provided by a certificate authority that will be trusted by the client machines. Finally make sure the setup.exe contains the production install URL. If not redeploy the solution from Visual Studio to the dev environment specifying the production install URL. Then xcopy the install.exe file from dev to production. (For details see ‘Moving Click Once Code to a new Server without using Visual Studio’)

Detailed Deployment Steps
Deploying Click Once Code From Visual Studio
Open Visual Studio and create a new WinForms or WPF project.

In the solution explorer right click on the project and select ‘Publish’ in the context menu.

The ‘Publish Wizard’ will start. Enter the development deployment path. This could be a local directory or web site. When first publishing the solution set this to a development web site and Visual basic will create a site with an install.htm page. Click Next. Select weather the application will be available both online and offline. Then click Finish.
Once the initial deployment is completed, republish the solution this time mapping to the directory that holds the code that was just published. This time the Publish Wizard contains and additional option.

The setup.exe file that is created has the install URL hardcoded in it. It is this screen that allows you to specify the URL to use. At some point a setup.exe file must be generated for production. Enter the production URL and deploy the solution to the dev folder. This file can then be saved for latter use in deployment to production. During development this URL should be pointing to development site to avoid accidently installing the production application.
Visual studio will publish the application to the desired location in the process it will create an anonymous ‘pfx’ certificate to sign the deployment configuration files. A production certificate should be acquired in preparation for deployment to production.

Directory structure created by Visual Studio

Application files created by Visual Studio

Development web site (install.htm) created by Visual Studio

Migrating Click Once Code to a new Server without using Visual Studio
To migrate the Click Once application code to a new server, a tool called MageUI is needed to modify the .application and .manifest files. The MageUI tool is usually located – ‘C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin’ folder or can be downloaded from the web.
When deploying to a new environment copy all files in the project folder to the new server. In this case the ‘ClickOnceSample’ folder and contents. The old application versions can be deleted, in this case ‘ClickOnceSample_1_0_0_0’ and ‘ClickOnceSample_1_0_0_1’.
Open IIS Manager and create a virtual directory that points to the project folder. Also make the publish.htm the default web page.

Run the ManeUI tool and then open the .application file in the root project folder (in this case in the ‘ClickOnceSample’ folder).
Click on the Deployment Options in the left hand list and update the URL to the new server URL and save the changes.

When MageUI tries to save the file it will prompt for the file to be signed.

This step cannot be bypassed if you want the Click Once deployment to work from a web site. The easiest solution to this for test is to use the auto generated certificate that Visual Studio created for the project. This certificate can be found with the project source code. To save time go to File>Preferences and configure the ‘Use default signing certificate’ fields.

Future deployments will only require application files to be transferred to the new server. The only difference is then updating the .application file the ‘Version’ must be updated to match the new version and the ‘Application Reference’ has to be update to point to the new .manifest file.

Updating the Configuration File of a Click Once Deployment Package without using Visual Studio
When an update to the configuration file is required, modifying the ClickOnceSample.exe.config.deploy file will not result in current users getting the new configurations. We do not want to go back to Visual Studio and generate a new version as this might introduce unexpected code changes. A new version of the application can be created by copying the folder (in this case ClickOnceSample_1_0_0_2) and pasting it into the application Files directory. Rename the directory ‘ClickOnceSample_1_0_0_3’. In the new folder open the configuration file in notepad and make the configuration changes.
Run MageUI and open the manifest file in the newly copied directory (ClickOnceSample_1_0_0_3).

Edit the manifest version to reflect the newly copied files (in this case 1.0.0.3). Then save the file. Open the .application file in the root folder. Again update the version to 1.0.0.3. Since the file has not changed the Deployment Options/Start Location URL should still be correct. The application Reference needs to be updated to point to the new versions .manifest file. Save the file.
Next time a user runs the application the new version of the configuration file will be down loaded. It is worth noting that there are 2 different types of configuration parameter; application and user. With Click Once deployment the difference is significant. When an application is downloaded the configuration file is also brought down to the client machine. The developer may have written code to update the user parameters in the application. As a result each time a new version of the application is down loaded the user parameters are at risk of being overwritten. With Click Once deployment the system knows if the user parameters are still the default values. If they are they will be overwritten with the new default values in the configuration file. If they have been updated by the user, they will not be overwritten.

Settings configuration view in Visual Studio

Production Deployment
When deploying the code to production it is prudent to disable the development and test deployment sites. This will allow errors such as incorrect URL to be quickly identified in the initial testing after deployment. If the sites are active there is no way to know if the application was downloaded from the production deployment and not redirected to test or dev.

Troubleshooting
Clicking the install button on the install.htm page fails.
Error: URLDownloadToCacheFile failed with HRESULT '-2146697210' Error: An error occurred trying to download <file>

This is due to the setup.exe file pointing to the wrong location.
‘The setup.exe file that is created has the install URL hardcoded in it. It is this screen that allows you to specify the URL to use. At some point a setup.exe file must be generated for production. Enter the production URL and deploy the solution to the dev folder. This file can then be saved for latter use in deployment to production. During development this URL should be pointing to development site to avoid accidently installing the production application.’

BizTalk: Receiving Multi Part Messages

Geordie — Fri, 28 Nov 2008 04:10:59 GMT

I have been working on a BizTalk project for a while now and after a bumpy start all has been going well. The current message that we are dealing with is the receipt and processing of a Purchase Order. The processing and mapping of the purchase order to the SAP orders schema went well and all I need to do was to receive the document from the customer. After a bit of a delay in getting an accurate sample message, I set to work on creating a process for receiving a PO from a Ponton server. On examining the sample message I found I was going to need to deal with receiving a Multi Part message.

So I looked at the SDK and searched online but found very little guidance. The samples and discussion where mainly about receiving messages from the POP3 adapter. In our scenario the message will be received by HTTP then dropped to a file. It will then be archived and processed.

How difficult can it be! 4 days latter I can answer the question. It is not easy if you have not dealt with this type of message before. So here is my guidance on this issue.

First I have created a sample project (the files 'BizTalk - Receiving.zip' can be downloaded from http://cid-96aebf00cffa01bd.skydrive.live.com/browse.aspx/.Public/Blog%20Posts) . The code, schemas, sample message, and binding file are all included. This should give you a good starting point to work out what you need to do for your project.

1. Sample messages. As mentioned the samples that I found were email messages. I was not sure if these samples were relevant to my project. With respect to the message it appears that BizTalk cares about the MIME 1.0, boundary and description declarations. As it happens the message I was receiving was missing all these parts. Also check out this post from Doug - http://www.tech-archive.net/Archive/BizTalk/microsoft.public.biztalk.general/2006-07/msg00134.html. Unfortunately the final solution was not posted but it helped me get closer to a solution.

2. You will need to make a Multi Part message in your orchestration. This is well covered in blogs and documentation. It is also straight forward. But here is the kicker. When are receiving multi part messages, the order you create the message parts matters!! Eric did a good job of documenting this ‘undocumented’ feature.
To summarize Eric’s post: The order of the message parts in displayed in VS is alphabetical, but creation order matters and may be different from what is displayed in VS. The message parts need to be created in the order they appear after the message has been split into its parts by the pipeline. The only way to determine the order of creation is to view the orchestration file in a text editor. You can find the message part order by examining the failed message in BizTalk Manager. Drill into the error, go the message tab and double click the message. The message parts should be listed on the left hand side.
If you are getting an Inner exception: ‘Wrong BodyPartException …’ and ‘Multi-part message has body part ‘XXXXX’, expected body part ‘YYYYYY’, and everything appears to be correct, check this as a possible cause. I lost over a day trying to resolve this issue!
The sample application contains 2 Multi Part messages only the second one works even though they look the same in VS.

3. You will need a custom pipeline. BizTalk uses the MIME component to process multi part messages. Even if the message is not a MIME message it can be processed by setting the ‘allow non MIME message’ property to true. The body part content type field is optional. Valid values are ‘text/xml ‘, ‘application/xml’… etc. The ‘Body part index’ is a 0 based index that identifies the body part by location in the message. It took me a while to discover that I also needed to add an XML dissembler in the pipeline as well. All the message part schemas are added to the ‘Document schemas’ collection.

Tricks that might help:

· Initially type the Multi Part message parts as System.Xml.XmlDocument. This will remove at least one area of possible error. This will allow you to identify other problems and resolve them one at a time.

· View the orchestration file in Notepad. Look for the definition of the multi part message. The order the parts are listed in the XML are the order the message parts were created. Remember creation order matters.

Sample Message

MIME-Version: 1.0

Content-Type: multipart/related; type="text/xml";

boundary="_968002A2-AAE4-43E0-90D3-83461FE91020_"

--_968002A2-AAE4-43E0-90D3-83461FE91020_

MIME-Version: 1.0

Content-Transfer-Encoding: binary

Content-Description: Header

<?xml version='1.0' encoding='UTF-8'?>

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

<soapenv:Header>

<eb:MessageHeader xmlns:eb="http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd" eb:version="2.0" soapenv:mustUnderstand="1">

... Rest of the Header Message....

</soapenv:Body>

</soapenv:Envelope>

--_968002A2-AAE4-43E0-90D3-83461FE91020_

MIME-Version: 1.0

Content-Transfer-Encoding: binary

Content-Description: POMsg

<?xml version="1.0" encoding="UTF-8"?>

... Rest of the Purchase Order Message....

</PurchaseOrder>

--_968002A2-AAE4-43E0-90D3-83461FE91020_--

Notes on Resolving BizTalk Connectivity Issues with Ponton clients

Geordie — Fri, 14 Nov 2008 19:00:14 GMT

Notes on Resolving Connectivity Issues

During the first stage of the Integration project a number of challenges were encountered. Some of these obstacles could have been avoided but we chose to resolve them so that we would have a solid solution for further development.

Challenges Encountered

· Server 500 error when posting messages to customer with a static port configuration and document that worked for other customers.

· Ponton responds with an ‘Internal Storage’ Error.

· The dynamic port fails with either a 500 server error or a 204 (StatusDescription=No Content) server error.

Issue 1

After a lot of work and Microsoft’s help we tracked the first error down to the customer’s server being unable to process HTTP 1.1 messages. The customer is currently running iPlanet 6 SP 10 on a Solaris 8 with a Ponton application server running WebLogic 8.1 SP6 also running on Solaris 8.

HTTP 1.1 includes chunking of messages at the HTTP level. In this case the customer’s server could not recombine the chunked message and failed with a 500 error. By default the HTTP chunking is turned on when a new static HTTP port is created in BizTalk. To turn this off click on the Configuration button in the Transport section of the Send Port’s General Property page. Under the Destination URL field there is a check box labeled ‘Enable chunked encoding’. By clearing this check box the HTTP 1.1 chunking feature will be disabled.

NOTE: While we were trying to resolve this issue the Microsoft tech ask me to run Microsoft Network Monitor 3.0 (NetMon) to capture the traffic so that we could determine if there was an obvious message problem. Due to the process used by NetMon it could not capture the HTTP traffic. It could however capture the HTTPS traffic. I’ve not sure why this is but it is worth noting.

Issue 2

The second issue was resolved with the assistance of Ponton. Our current customers use older versions of Ponton . Our new customer uses the 2.4 version of this product. It turned out that the use of the ‘Content-Disposition: attachment; filename="=?utf-8?B?QXR0YWNobWVudDF=?="’ property in the document header changed in the newer version. Older versions ignored this property. When we deleted this line from the header the ‘internal storage’ error was no longer raised by the Ponton server.

Issue 3

Finally when we tried to move the solution to a more dynamic design the customers server started to respond with 500 server errors again. Since the integration with our customer is over an SSL connection we contacted Ponton to see if they had a test server that uses HTTP for our analysis. When we connected with this server (Apache running on Linux) we received 204 server errors. If we tested the dynamic port with the same message against a BizTalk server running on a windows 2003 server it processed successfully.

The Microsoft Tech again tried to use NetMon to monitor the traffic with the same results. As a result several other techniques where used to capture the traffic to understand the differences in the messages.

By adding the following XML to the BTSNTSvc.exe.config file and running Sysinternals Debug Viewer we were able to monitor the traffic as it was generated in BizTalk.

<system.diagnostics>

</listeners>

</source>

</listeners>

</source>

</listeners>

</source>

</listeners>

</source>

</sources>

<add

name="System.Net"

type="System.Diagnostics.TextWriterTraceListener"

initializeData="System.Net.trace.log"

traceOutputOptions = "DateTime"

</sharedListeners>

</switches>

</system.diagnostics>

</configuration>

The first thing that was determined through this process was the default settings for a HTTP static port are not the same as those of the dynamic port. These settings were modified in an orchestration message assignment shape with the code shown below.

PontonMessage(HTTP.EnableChunkedEncoding) = false;
PontonMessage(HTTP.ContentType) = "multipart/related; type=\"text/xml\"; start=ebxml-header; boundary=\"_00000000-0000-0000-0000-000000000000_\"";
PontonMessage(HTTP.UseHandlerProxySettings) = true;
PontonMessage(HTTP.AuthenticationScheme) = "Anonymous";

Addressing these differences was the first place that we tried to resolve the issue. Unfortunately this did not resolve the problem.

The final test we did was to use a network sniffer called 'WireShark' to monitor the traffic. This allowed the text comparison of a static and a dynamic message. From this comparison the only differences were the date stamps, unique ID and the quotes around the content type parameters as shown below.

Dynamic Message:

Content-Type: multipart/related; type=’text/xml’; start=ebxml-header; boundary=’_00000000-0000-0000-0000-000000000000_’

The non Windows server required the quotes to be double quotes and could not process the message if single quotes were used. As a result the code int the Orchestration expression shape was changed as shown below.

From:
PontonMessage(HTTP.ContentType) = “multipart/related; type=’text/xml’; start=ebxml-header; boundary=’_00000000-0000-0000-0000-000000000000_’”;

To:
PontonMessage(HTTP.ContentType) = "multipart/related; type=\"text/xml\"; start=ebxml-header; boundary=\"_00000000-0000-0000-0000-000000000000_\"";

I hope this helps other people. This has been an interesting ride for me. Integration with non Microsoft systems can result in some unexpected problems.

Getting Document Values from Repeating Nodes in BizTalk

Geordie — Thu, 13 Nov 2008 23:48:16 GMT

To access a variable in a document in BizTalk is quite easy. First you go to the schema of the document and right click on the value you want to promote. Select Promote -> Show Promotions. To promote the variable as a distinguished property simply click the add button. If you messages are in a separate project make sure you build the solution before continuing. Accessing the promoted property in the orchestration is a simple process. Typing the message name, that represents the schema, in an expression shape. Intellisense will then guide you the rest of the way.

Now try that if the document variable that you require can have multiple values. As soon as you try to promote the field BizTalk will refuse to continue displaying the following dialog.

Currently I’m in the situation where I need that variable to start my mapping process. To get over this problem I have written a helper function is C#. The class is easily accesses from the orchestration. Simply reference the helper class project in the project that contains the orchestration.

using System;

using System.Collections.Generic;

using System.Text;

using System.Xml;

using Microsoft.XLANGs.BaseTypes;

using System.Configuration;

using System.IO;

namespace CustomerIntegration2.PAPINET.MessagingSupport

{

public class Helper

{

…

In an expression shape reference the helper class as shown below

CustomerNumber = CustomerIntegration2.PAPINET.MessagingSupport.Helper.GetCustomerID()

To allow the method to do its work it needs the message data. To achieve this I’m using an XPath query to grab the section of the message I need to process. In this case I’m also passing in mapping data as I need to convert the value to a customer ID. ‘BuyerDoc’ is a declared variable, of type System.Xml.XmlDocument, in the orchestration.

BuyerDoc = xpath(PAPINetPO, "/*[local-name()='PurchaseOrder']/*[local-name()='PurchaseOrderHeader']/*[local-name()='BuyerParty']");

Documenting C# Code

PsudoKnowledgeBase — Tue, 04 Nov 2008 15:30:30 GMT

An interesting application I was shown for documenting C# code is called Ghost Doc.

Roland's summary of the tool:- GhostDoc is a free add-in for Visual Studio that automatically generates XML
documentation comments for C#. Either by using existing documentation inherited
from base classes or implemented interfaces, or by deducing comments from
name and type of e.g. methods, properties or parameters.