So finally Microsoft has added this feature to its latest Office offering (2007). The free add-on can be downloaded here. I am not a fan of Adobe so this is a great move in my opinion. Adobe’s free PDF reader application is very close to spyware once you see what it installs and how many times it pings adobe when you fire it up. Thank you MS.
-B
So is BizTalk *really* smart enough to allow me to do request/response operations on both sides of my process without an orchestration in the middle? I set out to prove this scenario out for myself and wanted to share the results. I want to see if I can create a web service input into BizTalk, and have that request message trigger a request/response send port, and then take the response of that send port, and match it back to the response message of the original call. Make sense? So … First, you’ll see my web service below. It doesn’t do much. Takes a “customer” in, changes the customer name a bit, returns the same customer type back. Then I added a web reference to my project so that I’d get the web message types I needed. Next, I needed two maps. One to go from the “customer” passed into the BizTalk web service to the format expected by the service called by the send port. And, then a map to handle the reverse scenario (mapping the result of the send port’s service call back to the format of the initial caller). Then comes the ports. First, the receive location for the BizTalk-generated web service (which was built by generating a service out of schemas directly). This receive location does XML pipelines in both directions, and the receive port applies both the inbound and outbound mapping. The send port also does XML pipelines both directions. I used the new functionality in BizTalk Server 2006 which allows me to call a web service directly without using an orchestration. In my case, I referenced my BizTalk assembly, and because I added a web reference to my external service, I have the proxy class needed to call my web method. Now the moment of truth. I created a client app that calls the service. And, to make sure that the correct response finds its way back to the correct thread, I opened a couple instances of the client tool at once. After submitting web service requests from both simultaneously, I did indeed receive the correct message back to each client. So how the heck does this work? The End Point Manager (EPM) actually maintains subscriptions for the response message (which you can see if you’re really quick on the “run query” button). These subscriptions allow the EPM to grab the response message from the send port and correlate it back to the response message of the initial caller. I’m actually *really* impressed that this works. That’s fairly brainy stuff. Technorati Tags: BizTalk, Web Services
For this to happen, this would mean that BizTalk is able hold onto that initial calling thread, even as processing potentially hops physical machines, application boundaries and the like.
So is BizTalk *really* smart enough to allow me to do request/response operations on both sides of my process without an orchestration in the middle? I set out to prove this scenario out for myself and wanted to share the results. I want to see if I can create a web service input into BizTalk, and have that request message trigger a request/response send port, and then take the response of that send port, and match it back to the response message of the original call. Make sense? So … First, you’ll see my web service below. It doesn’t do much. Takes a “customer” in, changes the customer name a bit, returns the same customer type back. Then I added a web reference to my project so that I’d get the web message types I needed. Next, I needed two maps. One to go from the “customer” passed into the BizTalk web service to the format expected by the service called by the send port. And, then a map to handle the reverse scenario (mapping the result of the send port’s service call back to the format of the initial caller). Then comes the ports. First, the receive location for the BizTalk-generated web service (which was built by generating a service out of schemas directly). This receive location does XML pipelines in both directions, and the receive port applies both the inbound and outbound mapping. The send port also does XML pipelines both directions. I used the new functionality in BizTalk Server 2006 which allows me to call a web service directly without using an orchestration. In my case, I referenced my BizTalk assembly, and because I added a web reference to my external service, I have the proxy class needed to call my web method. Now the moment of truth. I created a client app that calls the service. And, to make sure that the correct response finds its way back to the correct thread, I opened a couple instances of the client tool at once. After submitting web service requests from both simultaneously, I did indeed receive the correct message back to each client. So how the heck does this work? The End Point Manager (EPM) actually maintains subscriptions for the response message (which you can see if you’re really quick on the “run query” button). These subscriptions allow the EPM to grab the response message from the send port and correlate it back to the response message of the initial caller. I’m actually *really* impressed that this works. That’s fairly brainy stuff. Technorati Tags: BizTalk, Web Services
For this to happen, this would mean that BizTalk is able hold onto that initial calling thread, even as processing potentially hops physical machines, application boundaries and the like.
Hello EDI World!
Today I respond to THE most often asked question: feature comparison of Edi support across the various releases of BizTalk Server.
The comparison was put together by me along with Microsoft and Partner field representatives with the objective of presenting an unbiased perspective on how the feature set has evolved over various releases.
I truly believe that the R2 Edi offering is very robust and ’enterprise’ ready; the claim is substantiated by a very impressive set of Beta customers including Microsoft IT.
As always comments and questions are welcome.
Namaste!
Suren
Feature Support across versions | BTS 2000/02 | BTS 2004/06 | BTS 2006 R2 | Comment |
ISA Segment modification at transaction set | Y | N | Y* | *Supported via creating TransactionSet specific Bts Party |
ISA11: US or other standard type | Y | N | Y |
|
ISA12: Interchange Control Version | Y | N | Y |
|
ISA13: Interchange Control Number (incrementing number) | Y | N | Y |
|
ISA15: Test or Production | Y | N | Y |
|
GS Segment modification at document/transaction level | Y | N | Y |
|
GS sender/receiver IDs allowed to be different than ISA | Y | N | Y |
|
Inbound Document IDs different than ISA & GS Outbound IDs | Y | N | Y |
|
GS01: Ability to change type of document | Y | N | Y |
|
GS04: Date (Ability to change format) | N | N | Y* | *UI to select format as: CCYYMMDD and YYMMDD |
GS05: Time (Ability to change format) | N | N | Y* | *UI to select format as: HHMM, HHMMSS and HHMMSSdd |
GS06: Change the control number | Y | N | Y |
|
GS07: Agency Code | Y | N | Y |
|
GS08: Able to put in standards version | Y | N | Y |
|
Custom EDI Schemas | Y | N | Y |
|
Organization/Party Setting | Y | Y (minimal) | Y* | *Including creating Party based off templates |
EDI document routing via document definition | Y | – | Y |
|
Automatic 997’s to trading partners | Y | Y | Y* | *Via party specific configuration. |
Outbound EDI reliable messaging via 997’s | Y | Y | Y |
|
EDIFACT Support | Y | Y (minimal) | Y* | *D93 to D05 per ISO 9735 v4.1 |
X12 Support | Y | Y (minimal) | Y* | *2040 to 5030 |
Ability to remove enumerators/codelists | Y | N | Y* | *Via VS/BtsEditor |
AS2 Send/Receive | N | N | Y |
|
Can migrate BTS02 custom XDR EDI schemas to EDI repository | – | N | N* | * Migration support BTS04 onwards |
Outbound Batching (accumulating multiple transaction types in a single transaction) | N | N | Y* | *Supports multiple release paradigms: Schedule, Count and External Triggered. |
Inbound Batching – Interchange XML (preserving an incoming ’batched’ interchange) or Transaction Set XML based off configuration options | N | N | Y* | *This is in addition to supporting inbound-debatching; i.e., splitting interchange into individual Transaction Set Xml. |
Interchange and Transaction Set Generation and Validation in Design Time via BTS Editor in VS | N | N | Y |
|
TA1 (Technical ACK) Generation and Reconciliation | N | N | Y |
|
Optional EDI and XSD Validation flags | N | N | Y |
|
Document format/definition at GS level | N | N | Y |
|
So what if I want to open up a BizTalk web services channel that accepts *any* XML message and then lets BizTalk Server figure out what do with that data? In considering ESB functionality, you often have the concept of generic ways to get messages “on the bus.” Given that BizTalk can be a perfectly good bus, with a robust publish-subscribe engine, it’s logical that BizTalk could support such a broad requirement. So what I need is a one-way “BizTalk web service” that accepts untyped content. There are a few viable options for doing this, but let’s go with the simplest. I’ve created a really basic orchestration with a single receive shape, and it accepts a message of type System.Xml.XmlDocument. Now I have no intentions of using this orchestration, but, I can use it to generate the service I want. I walked through the Web Services Publishing Wizard and “exposed” this orchestration as a service. What that gave me, was a SOAP service that looks like this … Given that nothing in the web service says I have to actually *use* the orchestration, I can use this process to create general on-ramp services. Now, I created a couple of send ports that have subscriptions on the BTS.MessageType property. I could easily do the same thing with Direct Bound orchestrations. These send ports (or orchestrations) are subscribers on message types, and aren’t concerned with the source of the message. Next I set up a Receive Port and Receive Location to accept the web service input. The key step is to use the XML Receive pipeline. This forces BizTalk to inspect the message, and promote the MessageType value. Finally, I built a simple application that uses this on-ramp service and publishes messages to the bus. You can see below that my web service method PostGenericDoc accepts a single parameter of type XmlNode. In my case, I send one of two different XML documents. This is a fairly powerful concept. Naturally I lose the ability to have a service contract, and run the risk of accepting content that has no subscribers, but, I also gain the ability to have a single service that be used by countless applications to simply and easily push messages onto the BizTalk bus. Technorati Tags: BizTalk, Web Services
Via Paul, this new paper on MSDN lays out some interesting tests to provide developers with information about some of the design impacts when using WF. These are always fun to read and then later to watch people hold them up as gospel about why they made really weird design choices. 🙂 Please, take these for what they are: guidelines and information. Don’t decide that you’ll never use a while activity because it is slower than some other activities. Test on your own system and add some complexity with custom activities if you really need the performance.
Just finishing up a week-long 12-hour-a-day BizTalk workshop for my SoCal customers, and wanted to post a few bits I built for the class. This post focuses on using promoted properties and distinguished fields on web messages. One apparent challenge when consuming an existing web service from within a BizTalk orchestration is the fact that you don’t appear to have a schema added to your project. Oh, you get “web message types” and so forth, but that’s not the same. What if you need to access a field in the input/output message in a message assignment shape, or, need to initialize a correlation set when you call a one-way service? When you add a “web reference” to your project, you get something like this … The obvious disclaimer applies: this is a auto-generated schema, and if I “update reference” I’d lose any promoted or distinguished distinction. Technorati Tags: BizTalk, Web Services
However, if you open up the reference all the way, you can drill through the references.map and you’ll find references.xsd. This XSD schema holds all the types used in the WSDL.
So, if you want to distinguish a field, or promote a property, it’s as easy as opening up this schema, and making that choice. Then you can easily access web message fields from within orchestration shapes, or, initialize new correlation sets on web service calls.
The Commerce Server product team will no longer be monitoring the Commerce Server newsgroups. Instead, we have nifty new forums set up on MSDN for both Commerce Server 2007 and earlier versions of the product. I think you’ll agree that this provides a significantly better experience for all of those concerned. Searchability is much better, for example, you can rate posts, and we can maintain a static FAQ there as the need arises.
Here’s the link: http://forums.microsoft.com/MSDN/default.aspx?ForumGroupID=294&SiteID=1
See you on the forums!
Just finishing up a week-long 12-hour-a-day BizTalk workshop for my SoCal customers, and wanted to post a few bits I built for the class. This post focuses on using promoted properties and distinguished fields on web messages. One apparent challenge when consuming an existing web service from within a BizTalk orchestration is the fact that you don’t appear to have a schema added to your project. Oh, you get “web message types” and so forth, but that’s not the same. What if you need to access a field in the input/output message in a message assignment shape, or, need to initialize a correlation set when you call a one-way service? When you add a “web reference” to your project, you get something like this … The obvious disclaimer applies: this is a auto-generated schema, and if I “update reference” I’d lose any promoted or distinguished distinction. Technorati Tags: BizTalk, Web Services
However, if you open up the reference all the way, you can drill through the references.map and you’ll find references.xsd. This XSD schema holds all the types used in the WSDL.
So, if you want to distinguish a field, or promote a property, it’s as easy as opening up this schema, and making that choice. Then you can easily access web message fields from within orchestration shapes, or, initialize new correlation sets on web service calls.
No organisation in their right mind would install a non trivial SQL Server system without furnishing a qualified DBA to look after it. Why do organisations not treat BizTalk in the same way?
On a scale of 0 to 10 where zero equals “If BizTalk stopped working someone might notice after a couple of weeks” and 10 equals “If BizTalk got borked, we would lose ELEVENTY BILLION DOLLARS every 10 mins” where is your BizTalk installation?
Ifthe Business impact of a BizTalk failure is low, say less than 2 or 3, then maybe this post doesn’t apply to you. Anything greater than 3 and you would do well to heed the following advice.
BizTalk isn’t a trivial product. Neither from a developer perspective nor an operations perspective. Its really important that the operations people responsible for keeping BizTalk running are adequately trained and knowledgable on how it works, what all its moving parts do, how to backup and restore etc. The worst case is when a Windows infrastructure guy (or team) or a SQL DBA is given the responsibility for managing BizTalk but isn’t given the training to do the job properly. Yes its a Windows Server product and Yes it uses SQL Server extensively but neither of these two groups of people are necessarily well qualified (with out specific training) to maintain a BizTalk installation.
At the very least, BizTalk operations people should be FORCED to read the manual – and given the time to get comfortable playing with BizTalk (not in production of course!).
There is BizTalk administration training available from various places (Microsoft included). I would say if your BizTalk installation is greater than a 5 on the business critical scale, proper formal BizTalk administration training for the operations team should be MANDATORY. (If for no other reason than as risk minimisation).
And my last question asI round out this post is: When was the last time your BizTalk Operations Team did a BizTalk failure/restore drill?
I would say, take your number on the scale, divide it by 2 and thats how many times per year you should run a restore drill.
Mark
Ps: ELEVENTY BILLION is my favourate fictional number.