A new BizTalk Server 2006 whitepaper has been posted on the subject of developing a transactional BizTalk Adapter using the Microsoft Base Adapter Classes.
You can find the paper here:
http://download.microsoft.com/download/3/7/6/376a6f6c-8c97-4ab5-9d5a-416c76793fbb/Transact_Adapter.doc
A new BizTalk Server 2006 whitepaper has been posted on the subject of developing a transactional BizTalk Adapter using the Microsoft Base Adapter Classes.
You can find the paper here:
http://download.microsoft.com/download/3/7/6/376a6f6c-8c97-4ab5-9d5a-416c76793fbb/Transact_Adapter.doc
A new Business Process Management (BPM) site was recently launched by Microsoft at www.microsoft.com/bpm.
Visit this site to learn how integrated, easy to use business process management solutions from Microsoft make it possible for organizations of all sizes to increase sales, reduce costs, optimize existing customer and supplier relationships, and recognize and react quickly to changing conditions to gain a real business advantage.
Some new scripts and utilities have been posted to the BizTalk Server 2006 Scripts site.
One is a command-line utility (provided with code) to purge local and remote MSMQ queues and send sample test messages to these queues. This could be very helpful when conducting performance lab engagements, resetting queues in between runs.
Another is a diagnostic tool that can help troubleshoot ESSO setup problems.
Enjoy,
– Doug
The sample scripts and utilities are not supported under any Microsoft standard support program or service. The sample scripts and utilities are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts, utilities, and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.
Some new scripts and utilities have been posted to the BizTalk Server 2006 Scripts site.
One is a command-line utility (provided with code) to purge local and remote MSMQ queues and send sample test messages to these queues. This could be very helpful when conducting performance lab engagements, resetting queues in between runs.
Another is a diagnostic tool that can help troubleshoot ESSO setup problems.
Enjoy,
– Doug
The sample scripts and utilities are not supported under any Microsoft standard support program or service. The sample scripts and utilities are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts, utilities, and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.
SQL Server 2005 offers many exciting new features. One of them is the support for Xml as a data type. On the surface, this looks great since BizTalk likes Xml. But, we come to learn that the Xml Data Type is not supported using the SQL Adapter inside BizTalk.
SQL Server 2005 offers many exciting new features. One of them is the support for Xml as a data type. On the surface, this looks great since BizTalk likes Xml. But, we come to learn that the Xml Data Type is not supported using the SQL Adapter inside BizTalk.
But, with a little effort you are easily able to accept Xml Documents that are all in one cell from SQL Server into BizTalk using the Receive Adapter.
Here is the scenario: The client is using a SQL table as a type of queue. Messages are writing as full Xml Documents into a single cell of the table, along with an id, datetime, and a status. This data needs to be inserted into BizTalk. In the past, I have used a windows service to send the messages to a MSMQ queue and then into BizTalk. My new approach is to use a simple stored procedure that I call from a Receive Port to extract out the Xml and update the states on the table.
In addition, you can use one Receive Location to receive many different message types. Then you can use message box routing (Direct Binding) to route many different message types to Send Ports or Orchestrations. You can also map on the Receive Port if needed.
The downside is you can not auto generate the schema using the SQL Schema Generation Wizard. You will need to generate them manually based on the Xml messages you will be putting into your queue table.
I have put together a sample complete with a sample database, stored procedure, and BizTalk code.
Download: Working with SQL 2005 XML Data in BizTalk 2006 Sample
This includes an importable MSI and Binding files if you want to build the code yourself. See the readme.txt file for more set up information.
Greg Young started
an interesting
discussion about Unit Testing BizTalk solutions; some good things to consider
are brought on. In general, I agree with Greg that testing BizTalk solutions isn’t
always easy, in particular because of dependencies and because of the level at which
BizTalk solutions are created (it is certainly a higher abstraction level than regular
C# code, for example). That, and the fact that the BizTalk engines are fairly complex
constructs, make it harder to test pieces of your solution in isolation, though it
is by no means impossible.
One point I wanted to take back from the discussion is Greg’s comment that testing
Schemas isn’t much of a problem and you’re probably going to get those on integration
testing. That is true if you’re dealing with simple schemas, but if you’re creating
complex Flat File schemas and doing things like debatching and a few of the other
advanced things that BizTalk schemas support, then being able to test your schemas
in isolation in a repeatable, automated fashion is a real blessing. Whether you want
to call this unit testing or not is open for debate, I’m sure, but it is a good thing
none the less.
At a higher level, Greg does bring a pretty significant question about whether it
is possible to do Agile development when using BizTalk. I’d sat it is certainly harder
than in other disciplines and with other tools, but not necessarily because of the
tool itself. One of the real issues here is the fact that Application Integration
(particularly on big projects) requires a somewhat larger investent in Architecture
up-front, because of the complexity of the issues involved and sometimes because integration
projects are composed of three or more providers (i.e. different companies) collaborating
with the customer to implement the required solution. This does require that you have
a more significant shared understanding of the problem at hand up-front and that some
key issues are covered right from the start.
Notice I’m not advocating a waterfall model, I’m just saying that some serious understanding
needs to be done at the start to ensure everyone is working towards the same goal.
There are many ways you can this done, without bringing the whole project to a stop
while the entire requirement analysis is done. For example, this initial phase is
a great time to prototype parts of the solution, create initial versions of
shared schemas, and explore potential solutions to some of the issues the project
has.
On some of the integration projects I’ve worked on doing this has been a key to the
success of the project, even allowing us to work after that in a far more agile fashion
while minimizing dependencies and even allowing us to complete the BizTalk part of
the solution well in advanced to other parts of the whole integration project.
I’m looking forward to exploring if some of the Agile
Architecture ideas can be used to make this initial part of the project more dynamic,
as well.
Some Biztalk links worth visiting:
Microsoft BizTalk Server 2006 Documentation Update (CHM)
http://www.microsoft.com/downloads/details.aspx?FamilyId=3294DDAF-9F67-409F-A92D-2F6070DC0D1A&displaylang=en