by stephen-w-thomas | Jan 26, 2006 | Stephen's BizTalk and Integration Blog
Recently I have been working a lot with the BizTalk Rules Engine (BRE) that comes along with Biztalk Server 2004.
Rather than the more common approach of using the BRE inside a BizTalk Orchestration passing in XML messages, I have been working with the rules engine in a pure .net scenario passing in .net objects as facts and working with a long term fact creator.
This approach uses the available API to call the BRE inside .net and passes in an array of facts to be operated on. The long term fact is used on the policy and loaded into memory the first time the policy is called. The supplied facts are passed out of the called policy with updated / changed values based on the rules inside the policy. This is very similar to a ByRef call.
I have put together simple sample that calls the BRE inside .net code using .net objects as facts and a long term fact creator. Make sure you read the ReadMe.txt file for additional set up information.
Sample: Biztalk Business Rules With .Net Components Sample
Basically, to run the sample build the two .net assemblies and GAC them. Then, load the Rule Policy XML using the Rules Engine Deployment Wizard. Run the WinForm. Note it may take up to 60 seconds for the policy to first be callable – to bypass this just restart the RuleEngineUpdateService (because you are not really working with BizTalk unless you have to restart a windows service).
The Long Term Fact will be created once each time you load the form – so if you keep hitting run the LTF gets reused. I have code commented out that will write to the event log when the LTF is created.
Have fun!
by stephen-w-thomas | Jan 26, 2006 | Stephen's BizTalk and Integration Blog
Over the course of the past few weeks, I found several different ways to completely break the Business Rules Engine. The common error I received is “Failed to Load”. I received this inside the Policies, Vocabularies, and when Importing the rules from XML.
The error looks something like this:
<IMG src="http://www.biztalkgurus.com/pics/BRE_FailedToLoadPolicy.JPG" P?
So why did this happen?
It seems to be caused from two reasons. Either one of the .net classes used inside the rules or vocabulary has changed (example: you are calling a method called AddCat(String) and now it is AddCat(int)) or the .net assembly is not in the GAC. The second is easy to fix by GAC’ing the .net components used in the rules. The first is more difficult.
To correct the first cause of the Failed To Load problem I have found two ways. Neither is very elegant.
The first way to get the vocabulary or policy to load is to manually edit the changed values inside the exported XML version of your rules. It seems the best thing to do is actually remove the whole function that is causing the problem. Now, this approach does not work very well unless you have your rules exported as XML.
The second way to correct this problem does not require the rules to be exported. It is to change the .net code back, re-GAC it, close the rules composure, reopen it, remove the uses of the code you want to change, save your rules, change your .net code, GAC it, change your rules to use the new .net code. Simple!
The moral of the story is to be cautious once you start using .net components inside the rules engine. If you need to make changes to methods used inside the rules, either version your .net code or plan ahead for your changes by removing the usage prior to making the change in the .net code.
Some other things to think about are:
– When working with a remote rules store, all .net components used must be installed locally in the GAC. Yes, this means that any business user who wants to view or update any rules through the rules composure must have all the .net components on there desktop. Not only that, they have to be the current version of the .net assemblies or the rules will not load.
– When working with Collections and ArrayLists you need to create your own Add method. You do not have access to the .Add property on the .net object.
– When deploying rules to the rules store the .net components have to be installed on the local computer.
Do not let this scare you away from using .net components inside your rules or to call your rules purely from .net. The Business Rules Engine has a lot of powerful features and best of all it is included with BizTalk Server 2004. Using .net helper classes and objects can greatly simplify rule development and decrease development time.
Updated: Sorry, original post said increase development time. I think using .net could help decrease development time.
by community-syndication | Jan 25, 2006 | BizTalk Community Blogs via Syndication
By way of background, let me take you way back to the proof-of-concept (POC), which is where the project I’m on had its genesis.
It was a competitive situation, where various vendors were given a set of requirements and a month to deliver an ESB-like solution that met them. Our team consisted of three people: Marty Wasznicky (Microsoft), Curt Peterson (Neudesic) and Todd Sussman (Neudesic). I was off doing other things at the time. Our team met all the objectives well ahead of the deadline, and then in fact proceeded to exceed expectations. At the end of the POC process, our team was the clear winner.
The basic capabilities of the POC were:
- Dynamic transformation (selecting and applying a map based on some external criteria, in our case the rules engine)
- Dynamic routing (contacting a UDDI directory [SOA Software] to get a SOAP endpoint URI)
- Integration with SalesForce.com
- Integration with AmberPoint
Transports involved were:
- SOAP (calling a SalesForce.com Web service)
- MQSeries
- File drop (as in all BizTalk demos and POCs :))
Although functionally the POC was very simple, it did prove out the various technologies, and showed that BizTalk was more than capable of playing a pivotal role in the client’s heterogeneous environment.
There were some interesting challenges with the SalesForce.com integration. Here’s what Curt has to say:
Integration with SalesForce.com’s Web Services interface, at first glance, appeared pretty straightforward. Unfortunately, the WSDL that was produced by SalesForce included nested Schema references that confused the BizTalk Web Services adapter wizard; we ended up creating the artifacts manually in BizTalk. The good thing is, all of this could be done manually, the wizards didn’t do anything “magic”.
This is of course all fluid, and that statement was true in June 2005. Your results may vary now. Here an internal Neudesic Field Note that Curt wrote up that you may find of interest if you’re up against this.
This is the last background/intro post, after this we’ll start delving into architectural issues, and the timelines will converge with my somewhat hectic reality.
by community-syndication | Jan 24, 2006 | BizTalk Community Blogs via Syndication
Flat file parsing in BTS2006 is pretty nice in general – you get a very specific error back in the error log if your incoming file is in the wrong format for the schema (or, put a more likely way, if you have buggered up creating the schema).
However, this vague error stumped us for a little while:
There was a failure executing the receive pipeline: “Orders.ContoFFPipeline.ContoFF, Orders.ContoFFPipeline, Version=1.0.0.0, Culture=neutral, PublicKeyToken=d5d6f7acdeb815af” Source: “Flat file disassembler” Receive Port: “RcvEnvelopedDocument” URI: “C:\FFIN\*.TXT” Reason: Unrecognized data in remaining stream
In our case this was due to a rogue carriage return at the end of the file (we had two instead of one!). Hope this saves someone some time!
by community-syndication | Jan 24, 2006 | BizTalk Community Blogs via Syndication
Here’s a braindump that I did for people with 2004 experience who are moving across to 2006. It’s just a very quick run through some of the new bits and pieces to look out for. It’s not complete, but it might be handy as the 50,000 ft view. It’s also written with a dev audience in mind and is not necessarily the view of my employer either! (Is that enough caveats?).
New Features
Functionally very smilar to 2k4 – nothing like the shift in experience from 2k2 to 2k4. It’s a “tidying up/more functionality” release, not a re-write.
The #1 new feature: You can zoom orchestrations in the development environment 😉
New BTS Admin tool which is actually useful (cf current admin console) and can be used to make modifications to your server. Also contains really good reporting, far nicer than HAT, for investigating failed messages.
New security group aimed at system operators who need to maintain, not modify, a server install
Includes lots and lots more adapters out of the box – eg MSMQ, POP3. Also all the iWay adapters such as JD Edwards, out of the box.
Really nice flat-file schema wizard, should save hours for anyone who needs to work with flat files.
Solution Deployment
Really, really, really, really nice. Collections of assemblies/bindings/resource files/etc are grouped into “Applications” within BTS. These applications appear as their own controllable group within server administrator. You can start and stop the whole thing (including orchs, send/receive ports) simply with a right click. You can also right-click and generate an MSI ready for import to another BTS2k6 box – and yes you can include multiple bindings files for multiple environments and it prompts you at MSI import time as to which environment you are setting up. Interesting to see how Scott Colestock makes use of this.
Server Installation
This is now much easier. All pre-requisites are supplied in a CAB file and installed for you, so no more hunting around for Patch A and Service Pack B.
Install is a two phase process: 1 – Install 2 – Configure so you can install to multiple boxes, then just run the configuration wizard to set up multiple identically configured BizTalk boxes. Config tool is now robust and usable (cf ConfigFramework.exe)
You can install on XP – but don’t, as you get a slightly different feature set and the install is slightly different. Better to stick to 2k3, unless your client’s servers will be running XP of course 😉
You can pre-create BTS Databases and the installer will use them and configure them. Just create an empty DB with the right name, and off you go. This is good for live deployments where you can create the database on teh server and disks that you want, precreate to a sensible size instead of forcing it to autogrow up to 2-3GB – a good way to boost performance.
Apparently, renaming of a biztalk server will be supported using a UI. This has yet to make an appearance in beta though.
Migration
BTS2004 projects “will” open fine in 2006. There have been reports of one single schema file that had issues, but it took 5 minutes to fix.
BAM
New BAM portal, which runs on ASP.NET. BAM can now hook into pipelines and message properties, not just orchestrations, so you can use it for pure messaging solutions too out of the box without dropping down into custom pipelines, custom components and the BAM API.
Can maybe use BAM for large-scale message tracking instead of TPE, with potential big performance gains as you get a dedicated database for it. This is just an idea some people are floating at the moment, and worth looking into for advantages/disadvantages
Samples
BTS2k6 ships with “Scenarios” – showing, eg, b2b, messaging, and so on. These are enterprise quality, complex applications showing best practice. Significant dev effort from MS into making these, so leverage them. Also probably contain useful components and utilities.
Random
Apparently XBox Live runs on BizTalk 2006 🙂
by community-syndication | Jan 24, 2006 | BizTalk Community Blogs via Syndication
Today’s tip is brought to you via the BizTalk 2006 Deep Dive training course that I’m on, run by Alan Smithof the Bloggers’ Guide to BizTalk fame..
In BizTalk 2004, if you wanted to create an empty output element in your target document via the mapper, you had a couple of options. You could either use a string concat functoid with one empty input parameter, or use a value mapper with ‘true’ and an empty string as its inputs. Bit tacky really, and in the case of a string concat also a bit slow as it uses inline C#.
Well rejoice, for in BizTalk 2006 there’s a new drop-down option on the “Value” field of the mapper that lets you pick “”.
Lovely! Especially handy if you are using the little-known but amazingly handy Property Demotiontechnique to populate message fields on the way out.
Incidentally, further to the system context properties described in the link above, you can also demote your own promoted properties from your own custom schema back into your message in the send pipeline.
by community-syndication | Jan 23, 2006 | BizTalk Community Blogs via Syndication
Hi all. Hope everyone watched as the Seahawks pummelled the Carolina Panthers yesterday. For our remote team members out in Charlotte … ouch … 6 total yards in the first quarter … ouch (I know it hurt Brian :). However, on a positive note, the Biztalk team is growing and has a lot of cool new work to do which we are planning right now. The bad news, though, is that you would probably at some level have to work with me. If you can get past that and are interested … the official blurb is below. Thx. Go Hawks!
We have several open positions in BizTalk team. We just started planning our next release of BizTalk server and have a lot of exciting ideas and opportunities. Send email to [email protected] if you want to participate in building next generation of the BizTalk server, or know someone who can be interested in growing his/her career in Microsoft.
by community-syndication | Jan 23, 2006 | BizTalk Community Blogs via Syndication
Exposing BizTalk interfaces as webservices is very easy using the ’BizTalk Webservice Publishing Tool’. In almost all cases this tool generates a correct functioning web service which does not need any code modification.
However, there are situations where tweaking the code of the generated web service is necessary. Recently I needed two different BizTalk interfaces to expose the exact same WSDL. Because the two interfaces had different names for namespaces and artifacts, the generated webservices and WSDL were not the same.
You can solve this by using the SoapExtensionReflector. The BizTalk Webservice Publishing Wizard generates a class called ’WsdlExtensions.cs’ for every webservice that is generated. By including this file in the generated VS.Net webservice project and adding the type in the ‘soapExtensionReflectorTypes’ section of the web.config (see header comments of
WsdlExtensions.cs), you’re able to control the generated WSDL for the webservice.
By default this file is generated with code for XML schema replacement in the WSDL, but you can use this to change other parts. For example, to override the SOAP service name, you can use:
public override void ReflectMethod()
{
ProtocolReflector reflector = this.ReflectionContext;
reflector.Service.Name = “MyNewServiceName”;
}
After recompiling the web service the service name in the WSDL is changed to the new value.
by community-syndication | Jan 19, 2006 | BizTalk Community Blogs via Syndication
I am working on a 56 processor (yes, that was FIFTY SIX PROCESSOR) BizTalk project for a very large company in the Bay area. As far as I know this is the largest BizTalk project on the go right now on the planet. I’m going to start blogging about our experiences as we move through this project, as I suspect lots of you BizTalkers will be *highly* interested in the challenges we are facing and how we are meeting them.
My role is architectural and tech lead for the BizTalk development side, I am responsible for the design and development of what is being called the “core engine”. There are MANY people working on this, on both the Java and .NET sides.
So what are we building? Well, I’m working in the ESB department, and everyone says we’re building an ESB. This makes perfect sense at the client site, but gets somewhat cloudy when you’re outside of the company, as there are multiple, sometimes conflicting, definitions of what an ESB really is. Many companies outside the Microsoft space have a product (or suite of products) that they call an ESB. In the Microsoft space, where I play, there is no single product that “is” an ESB. Rather, what most people define as an ESB is in fact a subset of what you get with the Microsoft technology stack.
There is an excellent position paper on Microsoft’s view of ESB available here
.
The key message in that paper, in my opinion, is: While Microsoft does not believe ESB is a stand-alone product category, customers looking to purchase an ESB will find that Microsoft offers a significant superset of ESB functionality at competitive price points.
To further quote from that paper, some of the common characteristics of the various ESB definitions include:
- Brokered communication. The basic function of an ESB is to send data between processes on the same or different computers. Like message-oriented middleware, the ESB uses a software intermediary between the sender and the receiver, providing a brokered communication between them.
- Address indirection and intelligent routing. ESBs typically include some type of repository used to resolve service addresses at run time. They also typically are capable of routing messages based on a predefined set of criteria.
- Basic Web services support. A growing number of ESBs support basic Web services standards including SOAP and WSDL as well as foundational standards such as TCP/IP and XML.
- Endpoint metadata. ESBs typically maintain metadata that documents service interfaces and message schemas.
To distill it down further to the simplest level, the basic idea is that you send a message to the ESB, and the message automagically gets routed to an end-point, perhaps with an optional transformation happening along the way. The endpoint could be just a protocol hop, or it could be a complex business process, or something in between. This can be thought of as a “services messaging layer”, or you could call it ESB-like. For my client, it will provide a core set of services that will be used across the enterprise for application integration, and will do so in a highly-scalable, reliable and extensible services-oriented manner.
It is my intention to post here on a regular basis, making this a true “living diary” for the project. I will be talking about the issues we run into, and how we solve them. I’ll walk you through the architectural decisions we’re making, and explain why. There are “soft” issues around this too, such as documentation, rollout plans, training… I’ll be writing about those also. This will be full-spectrum coverage. We’re facing and solving some tough engineering and business problems, and I am sure that a lot of what we’re up against will be very relevant to others that follow with similar projects.
Having said all that, this is a blog, and I’ll be posting entries as time permits. I’m thinking I’ll likely be writing blog entries nights, and while traveling (which I do a LOT of nowdays). Also, should I go dark for a while, that probably means that I’m spending all my time on the development effort. If that happens, I’ll make sure I catch up!
by community-syndication | Jan 18, 2006 | BizTalk Community Blogs via Syndication
Tip: temporarily commenting out chunks of an orchestration
Some of you will read this and say “doh, isn’t that obvious to everyone?”. Others will smack their foreheads and say “hey, what a cool tip”. So, to half of you: sorry to state the obvious, and to the other half: you’re very welcome.
Often while developing an orchestration it may be useful to “comment out” some of the steps. But… there is no “right-click route-around-this” capability on shapes, so what can you do?
You could make a copy of the orchestration, but a simple/easier/faster way is just through in a “decide” shape, make the condition “true==false”, then drag the shapes you want out of the flow into the false branch.
Of course, everything still needs to be compileable….
