CODit

Covast 2006 SYNTAX schema issues

by Pieter Vandenheede 3. September 2010 15:42

Some time ago, with a client using BizTalk 2006 and Covast Accelerator 2006, we suddenly had the following issue popping up in their event log:

There was a failure executing the send pipeline: "Covast.BizTalk.Pipeline.EDI.CovastEDISendPipeline, Covast.BizTalk.Pipeline.EDI.Default, Version=5.0.0.0, Culture=neutral, PublicKeyToken=68bef120a46b49ad" Source: "Covast EDI Assembler" Send Port: "sp_MySendPort" URI: "D:\BTS2006\DumpLocation\%MessageID%.edi" Reason: Message translation failed: (2217) Unknown error (-2217)

The source of the problem was Covast.
Somehow, it was no longer able to perform valid assembling and disassembling (both were failing).

After a lot of digging and research I finally came to the "Covast EDI Accelerator 2006 Reports" screens, hidden deep within the BizTalk Administration Console HAT :-)

When you double click the interchange which was in error, you saw the following error:

The format of the document has not been configured

Finally, this led me to the source of the problem.

Someone at the client fiddled around with one particular ASC file trying to add some extra segments to the schema to accompany a change in one of their flows. No harm done, but unfortunately when re-generating the XSD, he also regenerated the SYNTAX schema and deployed.

The result was that there were now 2 SYNTAX schemas deployed within BizTalk and Covast doesn't know how to handle that.
Reverting back to the old version of the flow fixed the error and after that we just removed the SYNTAX schema from the project, rebuilt and deployed and now it worked.

Reason for posting this is that at the time, neither search engine could come up with a decent answer, so hopefully someone benefits from this post.

Let us know in any case!

 

Pieter

 

Tags: , , , ,

BizTalk | EDI/AS2

Permalink | Comments (2)

Hosting WCF HTTP receive location inside BizTalk, without using IIS.

by sam 11. August 2010 14:12

Recently I was in Redmond for the BizTalk VTS Summit, with a bunch of colleague BizTalk experts from all over the world.  During one of the discussions we had, a question came up about the fact that it seemed that to host HTTP endpoints, it is required to have IIS as the real host configured.

After my suggestion that is was perfectly possible to bypass IIS in this process, it looked that quite a number of attendees didn’t know about this.  And that’s the reason why I decided to add it to our blog…

WCF-Custom vs WCF-CustomIsolated

First of all, I think it is a best practice to avoid using the non-WCF-custom adapters (like WCF-WSHttp, etc).  I always suggest colleagues and customers to use the WCF-Custom or WCF-CustomIsolated adapter, since they are the only adapters that provide the maximum capabilities of WCF in BizTalk.  The other WCF-* adapters only provide a subset of the various binding and behavior settings, specific for their binding, which results in an adapter change, when a more advanced setting is needed one day.

The WCF-Custom adapter, is the adapter that is used to host WCF endpoints inside BizTalk.  The WCF-Isolated adapter is hosted in a BizTalk Isolated Host, which is typically IIS.

The BizTalk WCF Service Publishing wizard

To expose an orchestration or a schema as a WCF service in BizTalk, the BizTalk WCF Service Publishing wizard is the typical way to use.  In this wizard, the orchestration or schema needs to be selected and a choice between three adapters is possible: WCF-BasicHttp, WCF-WSHttp, WCF-CustomIsolated. 

The last step of the wizard is used to create a web directory in IIS, where the BizTalk svc file will be created that hosts the custom WCF Service Host that will link through to the BizTalk Receive location. 

WCF Service type WCF Service Location

Unfortunately, the WCF Publishing wizard does not allow to select the ‘In-Process’ adapters.  All of the three adapters/bindings are only available through an isolated host and required IIS.

Hosting the endpoint in the BizTalk process

To host the endpoint inside the BizTalk process, we need to manually create the WCF receive location.  To do so, we just need to select the WCF-Custom adapter and use the desired binding: BasicHttpBinding or WsHttpBinding. 

The following steps need to be used for this:

  1. Create a new receive location with the desired name
  2. Select the WCF-Custom adapter and open the properties for this adapter
  3. Specify an address for the endpoint (picture 1) Take into account that when IIS is already running on the machine, you might need to specify a different available port.
  4. Select your binding (or use the customBinding for full flexibility) in the Binding tab page. (picture 2) and set all desired binding properties to their correct setting.
  5. In the Messages tab page, you can also specify that failed request messages need to be suspended and that exceptions should be returned to the consumer. (picture 3)

wcf1 wcf2 wcf3

Metadata publication

One downside of this way of work is the metadata publishing.  If you would query the exposed endpoint for the WSDL, you would get to see the WSDL of the generic BizTalk WCF Service Host with the 5 operations.

Therefore, it is needed to publish the metadata endpoint to IIS and provide that endpoint to the consumers of your in-process service.  But this way of work, is similar to the other protocols (like netMsmq, netTcp…)

Advantages

  • Consistent approach for all binding types, independent of protocol.
  • No extra configuration / deployment needed (specific IIS security on IIS application pools, etc)
  • Performance (no extra hop)

Sam Vanhoutte, CODit

Tags: , ,

BizTalk | WCF

Permalink | Comments (4)

Unattented installation of BizTalk & installation path

by vincent.rouet 3. August 2010 09:43

BizTalk can be installed using command line such as this:

"Setup.exe /quiet /addlocal all /IGNOREDEPENDENCIES /INSTALLDIR D:\program files\Microsoft BizTalk Server 2010 /s D:\Install\biztalk2010/configBiztalk2010.xml"

But we had an issue with the INSTALLDIR flag. Using the above path, the installation was failing with an error "Unable to load xml file: c:\users\insUser\AppData\Local\Temp\EBZ39051.tmp\1033\Autorun.xml"

After quite a lot of investigation the developer realised that the INSTALLDIR path with spaces in the name was the culprit. Using quotes around the path did not work either. Instead, the path should be its DOS short name. In order to do that, do the following:

1) Create the destination folder using the commande MKDIR on the destination drive
2) Get the DOS path using the command DIR /X from the destination drive
3) Run again using now the command such as in this example using the new path: "Setup.exe /quiet /addlocal all /IGNOREDEPENDENCIES /INSTALLDIR D:\PROGRA~2\MICROS~2\ /s D:\Install\biztalk2010/configBiztalk2010.xml". It should work fine!

Vincent ROUET, CODit

Tags: , , , ,

BizTalk

Permalink | Comments (6)

Using the LOB Activity in AppFabric workflows

by sam 4. June 2010 06:04

Yesterday’s post showed the usage of the new BizTalk mapper activity in Workflow Services and how it made these workflows more declarative and drastically reduced the amount of assignment code that was typically required without this new feature.

Another interesting BizTalk feature that is made available in AppFabric workflows is the LOB (Line of Business) connectivity.  This functionality gets installed with the new BizTalk WCF LOB Adapter pack.

This post will show how this feature is used in the Workflow designer.  I will be using the SQL LOB adapter, because that’s the easiest to demonstrate.  (No SAP or Oracle test system available at this time).  I continue on the workflow that was created in the previous post.

Metadata generation

1.       Right-clicking the workflow project, will show the Add Adapter Service Reference… menu item. 
 

 

2.       This shows the familiar Add Adapter Service Reference dialog box.  (Don’t you all agree this tool still looks too much of ‘Form1/Button1’ app? J).  After selecting the sqlBinding and providing the ServerName and DataBaseName, the connection was made.

3.       This showed all the available metadata for this connection.  It is possible to select stored procedures or tables that will be used in the process.

 

4.       Since the LoanRequest needs to be inserted in the database table, the Client contract type was specified and the correct table (LoanRequests) and operation (Insert) were selected.

 

Using the LOB activity.

 

1.       After clicking OK and performing a rebuild on the project, a new custom activity was added to the Workflow Designer toolbox.  Each operation (Insert, Update …) that was selected results in a specific activity that is part of a category with the database object name.

2.       Dragging this activity on the canvas, shows that the following parameters can be specified on the shape.

 

3.       I only declared the variable ‘saveLoanResult’ that represents the records that should be added to the database.   This variable was linked with the Rows parameter of the InsertActivity shape and is an Array of LoanRequest objects.

4.       The InsertResult parameter would return the result of the database activity, but this parameter is optional, so I did not link it with a variable here.

 

5.       The BizTalk mapper activity was added right before the InsertActivity shape.  Here, I defined a mapping between the loanRequest and the databaseInsert.

6.       Compiling the project and executing the workflow, resulted in a new record in my database table.
 

 

 

Conclusion

The power of connectivity and adapter is now made available to the AppFabric platform in a standardized and user-friendly way.  It is now also easy to connect to various LOB systems, databases and host systems (using the BizTalk Adapters for Host Systems). 

What is not clear at this point is how the licensing will work for these AppFabric features.  But more information about that can probably be expected by the time of the public release.

Sam Vanhoutte

 

Tags: , ,

AppFabric | WCF | Workflow

Permalink | Comments (29)