by community-syndication | Sep 2, 2004 | BizTalk Community Blogs via Syndication
What my last post demonstrated was actually how element reuse limits your ability to reusing an XML Schema definition. Last few weeks I saw still too many people reusing elements over and over without considering what consequences this can have when later on a schema has to be updated, reused or extended…
Regarding the sample, which was correctly identified as invalid by Martijn, Sachin, Peter and Wilco: indeed the XML Schema spec, paragraph 3.3.3 states that “If ref is present, then all of <complexType>, <simpleType>, <key>, <keyref>, <unique>, nillable, default, fixed, form, block and type must be absent, i.e. only minOccurs, maxOccurs, id are allowed in addition to ref, along with <annotation>.”
Unless it is very clear that in each and every situation an element will have the same name and exactly the same structure, an element reference is probably not safe to use. I prefer reusing types, wich allow for much more flexible reuse.
Thanks for the comments – you surprised me 🙂
Note: I know of a few people already but if anyone else is planning to use the BizTalk Server 2004 Transactional .NET Adapter I’ve written in a production environment, please get in contact. I’d like to know how this goes, what you plan to use it for and how any additional needs can be further addressed.
by community-syndication | Sep 1, 2004 | BizTalk Community Blogs via Syndication
Good news 🙂
I’ve a couple of GMail accounts to give away. Let’s make this a little contest 🙂 Since I’m curious how deep the average XML Schema knowledge goes, I’ll grant GMail access to the first two people that post a comment explaining what is wrong with the XML Schema below.
Note: XMLSpy will mark this schema as valid while it certainly is not! (Has anyone accidently noticed my aversion against this tool? :-))) )
<?xml version=”1.0″ encoding=”UTF-8″?>
<xs:schema xmlns:xs=”http://www.w3.org/2001/XMLSchema” elementFormDefault=”qualified” attributeFormDefault=”unqualified” targetNamespace=”myTargetNamespace” xmlns:tns=”myTargetNamespace”>
<xs:element name=”address” type=”tns:addressType”/>
<xs:element name=”customerDetails”>
<xs:complexType>
<xs:sequence>
<xs:element name=”firstName” type=”xs:string”/>
<xs:element ref=”tns:address” nillable=”true”/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name=”addressType”>
<xs:sequence>
<xs:element name=”street” type=”xs:string”/>
<xs:element name=”number” type=”xs:string”/>
</xs:sequence>
</xs:complexType>
</xs:schema>
by stephen-w-thomas | Sep 1, 2004 | Stephen's BizTalk and Integration Blog
Are you missing the feature of Application Pools that was available in BizTalk 2002? Need to limit your running Orchestrations? Well, I hope my BizTalk Design Competition submission will help you out.
I took that concept and created a Message Broker – Process Controller solution that will allow the user to limit the number of running Orchestration instances. In addition, the Orchestration parameters can be changed on the fly without stopping the Process Controller. The Process Controller can also monitor for suspended Orchestration instances and stop processing if a set limit is reached.
Core BizTalk 2004 Features Utilized
- Base Integration Pattern: Message Broker
- Custom Pipeline Component
- Property Promotion
- Content Based Routing
- Publish and Subscribe Messaging
- Direct Message Box Binding Receive Shapes
- Business Rules Engine
- Direct Interaction with External .NET Components Inside an Orchestration
- BizTalk 2004 WMI Interaction
Please see the documentation for more details. I think I have a total of 10 pages…
The download includes a MSI and the Source Code. The Source Code will install automatically through the MSI.
Download: Get the sample here! (880k)
by stephen-w-thomas | Sep 1, 2004 | Downloads
This fully documented solution shows how to use a process controller Orchestration to limit the number of running Orchestrations inside BizTalk Server 2004. This is similar to Application Pools in BizTalk 2002 that are no longer available in 2004. In addition, the rules engine is used to allow for real time updates to the number of running instances. This was an entry in the BizTalk 2004 Design Contest that ended in September 2004.
This sample shows a good use of the Business Rules Engine, Convoys, and Orchestrations.
This should work for both BizTalk 2004 and BizTalk 2006.
Get more information from the original blog post on this topic: https://www.biztalkgurus.com/biztalk_server/biztalk_blogs/b/biztalk/archive/2004/09/01/how-to-limit-the-number-of-running-orchestration-instances-in-biztalk.aspx
