by community-syndication | Jul 8, 2009 | BizTalk Community Blogs via Syndication
In this session Thiago introduces the new WCF based SQL Server adapter that is part of the BizTalk Adapter Pack 2.0. Learn the architecture behind the adapter, and how to use the SQL Adapter from BizTalk, or directly from .NET applications via the WCF service and channel models.
Register to attend
Free drinks and pizza provided!
Where: […]
by community-syndication | Jul 8, 2009 | BizTalk Community Blogs via Syndication
Hi folks, been a little quiet on the blogging front lately as myself and other BizTalk
Industry exerts have been busy creating a Series of Webcasts focused on BizTalk 2009
features.
I came up with this idea 3 months ago and we’re finally almost through the other side
– all the guys gave up their own spare time to share their field expertise and knowledge.
The line is great! comprising of MVPs and field experts whom have got runs on the
board.
I hope you enjoy the series, there’s a couple that are still to come, but we can’t
hold it back any further.
You can see them all here – http://cloudtv.cloudapp.net/Default.aspx?category=BizTalk (Alan
Smith has been very kind to offer hosting) – NOTE: not all the webcasts here
are part of the Series, most are 🙂 (I’m working on getting a sub-category)
|
Name |
|
Title |
Cloud TV Link |
PowerPoint |
Demo Code |
|
Richard Seroter |
|
Lap Around the ESB Toolkit 2.0 |
|
|
|
|
Mick Badran |
|
Integration With SharePoint from BizTalk
|
|
|
|
|
Mick Badran |
|
Implementing BizTalk RFID Mobile Solutions |
|
|
|
|
Kent Weare |
|
Creating a Highly Available BTS 09 Environment |
|
|
|
|
Kent Weare |
|
All you need to know about the SAP Adapter |
|
|
|
|
Alan Smith |
|
Improving BizTalk Orchestration Performance |
|
|
|
|
Alan Smith |
|
BAM Essentials Part 1 – Activities |
|
|
|
|
Alan Smith |
|
BAM Essentials Part 2 – Views |
|
|
|
|
Thiago Almeida |
|
All you need to know about the SQL Adapter
|
|
|
|
|
Miguel Herrera |
Field Expert |
All you need to know about the Oracle Adapter |
(coming soon) |
|
|
|
Mark Brimble |
Field Expert |
HL7 Revisited, a look at the HL7 accelerator |
Direct
Link
|
|
|
|
Zeeshan Shan
|
Field Expert |
BizTalkCreating Value in the Developer World |
(coming soon) |
|
|
|
Mike Stephenson |
|
ALM Part1 – Setting up a BizTalk Server |
Direct
Link
|
|
|
|
Mike Stephenson |
|
ALM Part2 – Implementing an Automated Build Process with BizTalk Server |
Direct
Link
|
|
|
|
Scott Scovell
|
Microsoft Virtual TS |
Implementing BizTalk RFID Solutions |
(coming soon) |
|
|
|
Scott Scovell
|
Microsoft Virtual TS |
EDI teaching the old dog new tricks with BTS 2009 |
(coming soon) |
|
|
>
by community-syndication | Jul 8, 2009 | BizTalk Community Blogs via Syndication
Hi all
2 and a half year ago, I wrote a blog post about looping around elements, which can
be found here: http://blog.eliasen.dk/2006/11/05/LoopingAroundElementsOfAMessage.aspx.
In this post, I mention two ways to do something per element in a message. One is
to use the XML (or flat file) disassembler to split the message into lots of messages
and have them handled individually, and the other is to do it inside an orchestration.
Since then, BizTalk has been updated such that you can now call a receive pipeline
from within your orchestration, which gives you the another way of looping through
elements inside an orchestration.
Often times, in the forums, users are suggested to loop through elements of a message
inside an orchestration. It is a fairly common approach if you want the subelements
of a message handled in the correct order, for instance.
This post is to make sure people know that looping around a message inside an orchestration
can have a serious performance impact.
Say you receive a large message – 100MB. You start looping around it inside an orchestration
and split it up into, say, 1000 messages of 100k each. Then, for each message you
call a web service or send out the message to some system. What will happen is, that
the orchestration will persist its state after each send shape, meaning that the 100BM
is written 1000 times to the messagebox. Persistence points are something you always
need to be aware of when designing your orchestrations, and with messages of 100MB,
even more so.
SO, don’t just loop around a message inside an orchestration because you can do it
when you absolutely have to.
Thanks
—
eliasen
by community-syndication | Jul 8, 2009 | BizTalk Community Blogs via Syndication
Hi all
Upon reading a forum post today, I stopped to think about the usage of custom XSLT
to completely replace the mapper, custom scripting functoids and the built-in functoids.
Some people can’t be bothered using the mapper and go straight to custom xslt whenever
a mapping is to be created. Others use the built-in functoids whenever possible. And
the rest go for some path in the middle, with functoids and the occasional scripting
functoid whenever the built-in functoids either can’t get the job done or seem to
be too troublesome to use.
The advantages of custom XSLT
-
Performance. It seems rather obvious that automatically generated
XSLT can’t perform as well as custom XSLT. So if you really need high performance,
use your own XSLT.
-
Maintainability. I will be using this argument against custom XSLT
as well 🙂 but in essence, some people think that having a map with perhaps 200 functoids
is too difficult to maintain. Sometimes you need lots of functoids in order to complete
some mapping task that can be easily done in XSLT. In that case, the XSLT can be more
readable and hence maintainable than using functoids.
The advantages of using the built-in functoids
-
Overview. Using the functoids can give a developer an overview of
what functionality a map provides, whereas custom xslt needs to be gone through and
“parsed” by a developer before he can understand what is happening.
-
Maintainability. (See, there it is again – in the opposite direction).
A BizTalk developer knows about maps and functoids. He does snot necessarily know
about xslt – and even if he does, he is not guaranteed to very proficient in it. By
staying with the functoids you give a BizTalk developer the best possible opportunity
to understand a new map he is going to maintain.
The advantages of using functoids and the scripting functoids
-
Everything is possible 🙂. Basically you can do what you want. Use
built-in functoids as much as you prefer and throw in scripting functoids if you think
the solution either can’t be done with the built-in functoids or is too troublesome
to do.
My preference
Well, those that read my blog regularly wont be surprised when I say that my preference
is to use the built-in functoids whenever possible. I turn to XSLT only when I cannot
solve my problem with the built-in functoids. And when I need XSLT, I always use custom
scripting functoids to supplement the other functoids, so I let as much of the job
as possible be handles by built-in functoids. I never use custom XSLT to replace the
map. My main reasons for this are:
-
Maintainability. I truly believe that it is easier for a new BizTalk
developer to troubleshoot and/or change an existing map if only built-in functoids
are used.
-
Overview. If a BizTalk developer opens up a map and sees lots of
scripting functoids, he needs to open them all up and examine the code inside it in
order to know what the map does. And after looking at 5 different scripting functoids,
he needs to go back and look at the first again. Really annoying!
If I am doing a rally complex map where the number of custom scripting functoids is
larger than the number of built-in functoids, I might consider using a custom XSLT
script but this haven’t happened yet 🙂 And also, if i run into really serious performance
issues, I will consider it as well, off course.
Just my thoughts.
—
eliasen
by community-syndication | Jul 7, 2009 | BizTalk Community Blogs via Syndication
Hi all
When trying to help the guy I wrote about in http://blog.eliasen.dk/2009/07/07/DistinguishedFieldNotWorking.aspx getting
his distinguished field working, another guy suggested that he just used he xpath
function instead of trying to get the distinguished field working. Now, he actually
ended up using the xpath function because he had a reserved word in the xpath statement
to the field he needed to access the field, but I thought I’d just write a post about
why the xpath function should be avoided and perhaps generalize the post to the usage
of promoted properties, distinguished fields and the xpath function. When to use what
and why
Why use distinguished fields over the xpath function
-
Readability. Inside an expression shape, it is much easier for a
BizTalk developer to look at “Message.MyElement.MyField” than it is to look at “xpath(Message,
“string(/*[local-name()=’MyElement’ and namespace-uri()=’http://mynamespace.com/something/somethingmore’]/*[local-name()=’Myfield’
and namespace-uri()=’’])”)”
-
Maintainability. If you need to change a schema at some point, the
distinguished field is automatically updated to correspond to the new xpath expression
that points to the relevant field (if you are using the BizTalk Editor, that is).
If you use the xpath function, you need to find ALL occurrences of the xpath function
in your entire solution that has an xpath expression that needs to be updated.
-
Performance. If you use the xpath expression to get values form a
message, then the entire message needs to be loaded from the database and the xpath
expression is then evaluated. Distinguished fields, on the other hand, are kept in
the context of the message and is therefore loaded quickly at runtime.
Why use promoted properties over distinguished fields
-
Routing. Only promoted properties can be used for routing in the
internal publish/subscribe engine if you need to route based on the content of a message.
-
Correlation. If you need to correlate a received message into a specific
instance of your orchestrations, then you need to do this using promoted properties,
as these are the only properties that can be added to a correlation type. This makes
sense when you think of it, because correlation is really just runtime routing – setting
up the correct subscriptions at runtime that will make the message hit the correct
orchestration instance. And routing can only be done with promoted properties, hence
these are needed for correlation.
-
Tracking. You cannot track distinguished fields – for tracking, you
need promoted properties.
Why use the xpath function
-
Distinguished fields cannot be used because there is a reserved word in the path of
the xpath expression
-
Distinguished fields cannot be used because you need to set or read a value from a
reoccurring element
Why use distinguished fields over promoted properties
-
Performance. You want to keep the number of promoted properties as
low as possible, since the messaging engine really needs as few promoted properties
as possible to evaluate when finding out which subscriptions match an incoming message
that is published to the MessageBox.
So, to sum up: Use distinguished fields whenever possible, switching only to xpath
function or promoted properties if really needed.
—
eliasen
by community-syndication | Jul 7, 2009 | BizTalk Community Blogs via Syndication
Hi all
A guy on the forums posted a very small schema, in which he had promoted an element
as a distinguished field.
His schema was this:
<?xml version="1.0" encoding="utf-16" ?>
<xsd:schema xmlns:b="http://schemas.microsoft.com/BizTalk/2003" attributeFormDefault="unqualified"
elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="outbound_task">
<xsd:annotation>
<xsd:appinfo>
<properties xmlns="http://schemas.microsoft.com/BizTalk/2003">
<property distinguished="true"
xpath="/*[local-name()=’outbound_task’ and namespace-uri()=”]/*[local-name()=’task’
and namespace-uri()=”]/*[local-name()=’task_id’ and namespace-uri()=”]" />
</properties>
</xsd:appinfo>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="task">
<xsd:complexType>
<xsd:sequence>
<xsd:element
minOccurs="0" name="task_id" type="xsd:decimal" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
His issue was, that when he tried using the distinguished field in an orchestration,
the task_id field just didn’t show up in intellisense. And if he just entered the
complete value in the expression shape (like this: Message.task.task_id) then he got
a compile time error.
I messed around with it a lot, trying all sorts of stuff, but ended up with a quite
simple solution: the word “task” is a reserved word. For a complete list of the reserved
words, take a look at http://msdn.microsoft.com/en-us/library/aa547020.aspx.
So, basically, renaming the “task” element to “Task” or something completely different
(but still avoiding any reserved words) will work.
Hope this helps.
—
eliasen
by community-syndication | Jul 7, 2009 | BizTalk Community Blogs via Syndication
That Alan Smith is always up to something. He’s just created a new online community for hosting webcasts about Microsoft technologies (Cloud TV). It’s mainly an excuse for him to demonstrate his mastery of Azure. Show off. Anyway, I recently produced a webcast on the ESB Toolkit 2.0 for Mick Badran Productions, and we’ve uploaded […]
by community-syndication | Jul 7, 2009 | BizTalk Community Blogs via Syndication
Most of the sample from Microsoft have so far been more about HOW to use “Oslo”, rather then WHY and WHEN. This has brought many developers to struggle about what to make out of “Oslo”, and how to put it in good use.
There are, however, several very interesting community posts about Oslo. But most of them are about M Grammar, and very few (I haven’t seen any) has been about the “Repository”.
M Grammar, is without a doubt a more “sexy” technique, as the Repository is nothing more than a SQL store for your models. – BUT I’m willing to bet that the Repository will play a very significant part in the future of any Microsoft technology. By writing this article, I hope to broaden your vision of how to use “Oslo”, and envision where Microsoft is going with the it.
Service Configuration => “Oslo” Repository;
A service host, hosts one or more services. It is created by a service host factory which, by default, loads all service configurations (bindings, services and behaviors) from one configuration file. The default factory is System.ServiceModel.Activation.ServiceHostFactory.
The samples in this post will show you how you could load the configurations for all your services from ONE “Oslo” Repository, rather than from many configuration files. As if all your services would share the same config file.
The sample above would of course work for any number of web servers accessing the same Repository database.
To accomplish this we need:
- A “Oslo” model representing system.serviceModel. The January release of “Oslo” where shipped with the system.serviceModel model. However it was cut out in the May release, so I just created my own.
- A custom service host factory that loads Services and endpoints, along with all bindings and behaviors. I didn’t bother to make this to generic, so it only supports basicHttpBinding, wsHttpBinding, netTcpBinding and of course mexHttpBinding.
– “So what?”
Actually, I think this is a pretty big deal. Having one single repository for all your services, means one single store for managing and configuring these services. – And what better tool to use than the “Oslo” Quadrant!
Try it out:
- If you haven’t already installed the Oslo May CTP release, you can find it at the “Oslo” Developer Center.
- Download the zip file and open the bLogical.ServiceModel.m file using “Intellipad”.
- In “Intellipad”, switch to “SQL-Preview” by using the “M mode” in the menu bar.
- Open SQL Management Studio, create a new query window and select the Repository database.
- Copy the T-Sql from “Intellipad”, paste it in to the query window and execute it. This will create all the Tables, and populate them with sample data.
- Open Visual Studio 2008, and create a new WCF Service by selecting “New Web site”. Don’t change the name of the service, as the samples created in step 5 assumes your service is called “Service”, and its interface is called IService. If you do want to change the name or use it for an already existing project, make sure to to do the changes in the repository.
- Add the bLogical.Oslo.ServiceHostFactory project to your solution.
- Open your .svc file and add the bLogical service factory:
<%@ ServiceHost
Language="C#"
Debug="true"
Service="Service"
CodeBehind="~/App_Code/Service.cs"
factory="bLogical.Oslo.ServiceHostFactory.ServiceHostFactory"
%>
Run the service!
HTH
Special thanks to Yossi Dahan, for encouraging me to do this article.
//Mikael
by community-syndication | Jul 6, 2009 | BizTalk Community Blogs via Syndication
My webcast on the new WCF SQL Adapter has been made available on Cloud TV, a great initiative started by Alan Smith. Clout TV is a community based website for hosting webcasts relating to Microsoft technologies.
Here’s the link to the presentation:
http://cloudtv.cloudapp.net/ViewWebcast.aspx?webcastid=2521554268962766719
There are several other webcasts on the site already, including two others by Kent Weare […]
by community-syndication | Jul 6, 2009 | BizTalk Community Blogs via Syndication
Hi all
A long time ago, I had a post about the toolbox in Visual Studio keeping old functoids
on it and crashing and stuff.
The post can be found here: http://blog.eliasen.dk/2006/12/05/RemovingFunctoidFromToolbox.aspx (Note
the comments).
With this post I just wanted all to know that the path to the toolbox* file that should
be deleted on a Windows Server 2008 with visual Studio 2008 is C:\Users\<User>\AppData\Local\Microsoft\VisualStudio\9.0
Hope it helps
—
eliasen