Microsoft has been putting lot of effort in documentation and it shows when they have recently released Microsoft BizTalk Server Best Practices Analyzer v1.1 which performs configuration-level verification by reading and reporting only. The Best Practices Analyzer gathers data from different information sources, such as Windows Management Instrumentation (WMI) classes, SQL Server databases, and registry […]
We are currently working on an Oracle EBS (aka Oracle Apps) Adapter for the next release of Adapter Pack, along with a SQL Server Adapter. The Oracle EBS adapter will be built using WCF LOB Adapter SDK. At a high-level, we are planning to have the following set of features in the adapter:
Do you use XMLGateways and Business Events in your Oracle E-Business scenarios and want to see it as part of the Oracle EBS adapter? We would like to hear about any other specific features that you would like to see in the Oracle EBS adapter.
Please do let us know if you would like to enroll in the Technology Adapter Program(TAP). As part of the TAP program, you get a chance to work closely with the product team to identify features and requirements for the product, try out early drops of the adapter and help Microsoft validate the features for quality and production-readiness.
We are currently working on an Oracle EBS (aka Oracle Apps) Adapter for the next release of Adapter Pack, along with a SQL Server Adapter. The Oracle EBS adapter will be built using WCF LOB Adapter SDK. At a high-level, we are planning to have the following set of features in the adapter:
Do you use XMLGateways and Business Events in your Oracle E-Business scenarios and want to see it as part of the Oracle EBS adapter? We would like to hear about any other specific features that you would like to see in the Oracle EBS adapter.
Please do let us know if you would like to enroll in the Technology Adapter Program(TAP). As part of the TAP program, you get a chance to work closely with the product team to identify features and requirements for the product, try out early drops of the adapter and help Microsoft validate the features for quality and production-readiness.
Microsoft has just released a new version(1.1) of the BizTalk Best Practices Analyzer (BPA). For those of you not familiar with it, it’s an awesome tool that looks at your infrastructure, compares it to rules gathered from a variety of experts, and issues a report with recommendations. It does not actually change anything, it just scans the environment and spots opportunities for improvement, provides an explanation and a link to further documentation for anything it reports on. To give you an idea of scope-of-change, version 1.0 had 77 rules, version 1.1 has 220. This is an EXTREMELY important tool. BizTalk solutions typically span a wide swath of the Microsoft technology stack, and mis-configurations outside of BizTalk (eg: IIS, file system, database, etc) can have a big impact on the performance of a BizTalk solution. The BPA looks across the stack, and identifies potential problem areas.
Download it here:
http://www.microsoft.com/downloads/details.aspx?FamilyId=DDA047E3-408E-48BA-83F9-F397226CD6D4&displaylang=en
Along the same lines, I blogged recently about the new BizTalk operations guide which is an invaluable reference source. If you have not looked at it yet, you should do so, it’s well worth your time. See that post here: http://geekswithblogs.net/bloesgen/archive/2008/02/21/119857.aspx.
The following are some screen shots from the Best Practices Analyzer at work:
Doing a scan:
List report:
Drilling into an issue and asking for an explanation (this is in one of my VMs, no cause for alarm :)):
I’ve just uploaded a new version of my PipelineTesting library.
This one contains just a few minor modifications: A few improved unit tests, and new
methods to make it easier to create multi-part messages to use as pipeline inputs.
Here’s an example of the last one:
IBaseMessage message = MessageHelper.Create(
"<body>This is the body part (part1)</body>",
"<body>This is the part2</body>",
"<body>This is the part3</body>"
);
Assert.AreEqual(3, message.PartCount);
The new MessageHelper.Create() method takes a params array of strings as argument.
Each one will get loaded as a separate message part, with the first one being marked
as the body part. There’s also a second overload which takes a params array of Stream
objects.
As usual, you can download the code from here: PipelineTesting.zip.
BizTalkIt’s always a good practice to validate your incoming messages against schema to make sure you discard useless messages up front and avoiding unnecessary processing.
BizTalk allows you to verify the validity of the incoming Xml message against deployed schema in few different ways. Some of the easy options are
In both the scenarios, the incoming message is validated inside a receive pipeline and an exception is raised if the message fails validation, eventually suspending the pipeline service instance. You’ll see description of the error messages both in event log and suspended instance with associated messages in the admin console.
Here are the few challenges in a real world situation:
Our (improved) requirements are:
NOTE: Attached sample code got all the relevant materials discussed in this article.
Sample Schema, Extended Pipeline component code, Sample receive pipeline, Sample Orchestration and required binding file.
Test Schema definition:
Restrictions:
employeeId: Is a string that contain only numbers of 5 chars long.
jobSpecification: Manager, Programmer, Analyst.
firstName/lastName: Can only be of alphabets.
Validation using XmlReceive default pipeline:
You can enable validation inside the default XmlReceive pipeline by setting ValidateDocument property to true. But there is a trick, if you enable this property you need to set the DocumentSpecName property as well specifying the schemas. Unfortunately it doesn’t resolve the schemas automatically, and you’ll see clear exception message saying
There was a failure executing the receive pipeline: “Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35” Source: “XML disassembler” Receive Port: “Receive.XmlReceive” URI: “C:\@Blog\XmlValidation\FileDrop\XmlReceive\In\*.xml” Reason: Validation can only be performed when document schemas are provided.
DocumentSpecName property must be specified in this format (it’s not documented clearly and took me a while to figure out)
DDL.Demo.Schemas.EmployeeRequest, DDL.Demo.Schemas, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c2b0cafd9314ef3e
DDL.Demo.Schemas: Schema .net namespace
EmployeeRequest: Type name defined for the Schema
DDL.Demo.Schemas: Fully qualified assembly name.
(You can easy get these values from BizTalk Admin Console by opening the schema)
If you receive more than one message type inside the same pipeline, you can add multiple DocumentSpecNames by splitting it with a pipe (|) symbol.
Validation using XmlValidator pipeline component:
Configuring and performing validation using the out of the box XmlValidator component is simple. Follow these easy steps:
The XmlValidator component should resolve the schema dynamically and validate the message against the schema. If there are any exceptions it will raise an exception and suspends the instance.
Testing:
I created a sample message as shown below
There are 3 invalid elements in the schema. employeeId is not in the right format and both first name and last name got some invalid characters (according to our schema definition only alphabets are allowed).
Firing the above message with validation enabled (either one of the above methods) will raise the exception and suspends the service instance. The exception message will be:
The document failed to validate because of the following error:”The ’employeeId’ element has an invalid value according to its data type.” .
Correcting the above error in the message and firing it second time will show the second validation failure as below
The document failed to validate because of the following error:”The ‘firstName’ element has an invalid value according to its data type.” .
Extended XmlValidation pipeline component:
In most of the cases it not useful to get one error message at a time, consumers would like to receive all the validation failure messages at one go, so that they correct all of them and send the message back.
This problem forces us to write the extended XmlValidation pipeline component, which basically extend the functionality of the default BizTalk XmlValidation component to raise all the errors at one go and also give a serialized exception message, which you can easily to map it to a customer specific response message.
The complete source code is available for download here.
Firing the message via the extended validation component will raise the following error description.
There was a failure executing the receive pipeline: “DDL.Pipeline.ExtendedXmlValidation, DDL.Pipeline, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c2b0cafd9314ef3e” Source: “Pipeline ” Receive Port: “Receive.ExtendedXmlValidation” URI: “C:\@Blog\XmlValidation\FileDrop\ ExtendedXmlValidation.In.ReceivePort\In\*.xml” Reason: Exception of type ‘DDL.PipelineComponents.XmlValidationException’ was thrown.NodeName: employeeIdNodeValue: 12 NodeNameSpace: . Severity: Error. Description: The ’employeeId’ element has an invalid value according to its data type.. NodeName: firstNameNodeValue: firstName007 NodeNameSpace: . Severity: Error. Description: The ‘firstName’ element has an invalid value according to its data type.. NodeName: lastNameNodeValue: lastName008 NodeNameSpace: . Severity: Error. Description: The ‘lastName’ element has an invalid value according to its data type..
So, you can see clearly you got all the validation failures at one go and also you got extra information like the node value, severity of the error (whether its error or warning) etc.
Sending the validation failure message back to caller:
One of the other big challenges is sending this exception message to the caller or to some other system to process. Just plainly terminating the service is instance is not useful most of the time.
We utilised BizTalk 2006 ability to call Receive pipeline within orchestration to achieve this.
First a response schema is defined as shown below, which contains an errors collection node with description and nodeName elements inside.
The sample orchestration looks like:
Inside the Schema Validation expression shape we called our custom pipeline as shown below:
Microsoft.XLANGs.Pipeline.XLANGPipelineManager.ExecuteReceivePipeline((typeof(DDL.Pipeline.ExtendedXmlValidation)),MSG_EMP_REQ);
An exception handler is created to catch exceptions of type Microsoft.XLANGs.Pipeline.XLANGPipelineManagerException
Exception message is created inside the 2nd construct shape using the following statement
schemaException = (DDL.PipelineComponents.XmlValidationException)exSchemaValidation.InnerException;
MSG_XML_VALIDATION_ERROR = schemaException.ErrorCollection;
Note we are accessing the innerException property of the XLANGPipelineManager exception.
If there are no schema validation exceptions a response message will be constructed normally (first construct shape). Else if the control goes to the exception handler block a map is applied to transform the errors from XmlValidation to the response message as shown below
The response message will look like:
Setting up the sample file:
Unzip the content to C:\@blog\XmlValidation folder. Open DDL.Demo.PipelineComponent solution and compile it, open XmlValidation.sln build and deploy it. Binding file is present.
Nandri!
Saravana
One of the glaring omissions from InfoPath 2007 is integration with non SQL Server data repositories. For retrieving reference data (query data), your only choice is SQL Server. That’s lousy. For submitting data, your only choice is SQL Server or Microsoft Access, and, you can only submit to a database when using the thick client […]
A few days ago I’ve received the Microsoft BizTalk Server MVP award for fourth consecutive year. Once again I am grateful to the people involved in the evaluation process. For the last twelve months I’ve been involved in several projects with the Connected…(read more)
While developing BizTalk projects I frequently end up developing mini-tools to automate small and/or repetitive administration tasks. One of these, which I recently generalized, I use to turn on or off multiple "Enable Failed Message Routing" options.
Here’s how you can use it:
TurnFailedMessageRouting * on DbServer – turns on the option in all the send ports and receive locations in all the applications in the configuration database in server DbServer.
TurnFailedMessageRouting MyApp off DbServer – turns off the options in all the send ports/receive locations of application MyApp in the configuration database in server DbServer.
So:
The source code is in the attachment, it’s pretty simple, use and change it freely. Most of it uses the BtsCatalogExplorer functionality.
(note: this can be done using script, I just prefer coding in C#).
Download at my SkyDrive: BizTalk2006.TurnFailedMessageRouting.zip
As you all know, the BizTalk%u00ae Adapter Pack was released earlier this year and includes WCF based adapters for SAP, Oracle DB and Siebel. We have recently posted a detailed presentation about the Adapter Pack on Channel 9. You can view it at http://channel9.msdn.com/ShowPost.aspx?PostID=394792. Hope you find it useful. Look forward to hearing your feedback.