by community-syndication | Jul 9, 2007 | BizTalk Community Blogs via Syndication
An adapter built using WCF LOB Adapter SDK can be used in variety of topologies and scenarios. Follow your organization’s n-tier architecture principles and design patterns to determine where the adapter can fit best for your requirements.
Usage Pattern 1 – Consume adapter in a .NET managed application (Point-to-Point)
Design Time: In Visual Studio 2005, use in project templates such as Windows Application, Class Library and Console Application.
1.1 Outbound
At design-time, use Add Adapter Service Reference Visual Studio Plug-In to generate the WCF Client Proxy for use in the .NET application.
1.2 Inbound
At design-time, use Add Adapter Service Reference Visual Studio Plug-In to generate the WCF Service Interface (callbacks) for use in .NET application.
Usage Pattern 2 – Consume adapter in BizTalk Server using BizTalk WCF Adapter (Broker, Bus)
Design Time: In Visual Studio 2005, use in project templates such as BizTalk Server Project. Please note that this scenario is only applicable to BizTalk Server 2006 R2, since versions prior to R2 do not have support for WCF.
2.1 Outbound
At design-time, use Consume Adapter Service BizTalk Project Add-In to generate the XML Schema for input and output messages. The Consume Adapter Service BizTalk Project Add-In tool also generates a BizTalk Port Binding Configuration XML File that can be used to configure physical send port(s) at deployment time.
2.2 Inbound
At design-time, use Consume Adapter Service BizTalk Project Add-In to generate the XML Schema for input and output messages. The Consume Adapter Service BizTalk Project Add-In tool also generates a BizTalk Port Binding Configuration XML File that can be used to configure physical receive port(s) / locations at deployment time.
Usage Pattern 3 – Consume adapter in a Windows Workflow Foundation (WF)
Windows Workflow Foundation (WF) provides a general framework for defining workflows and a robust runtime engine that allows you to host and interact with the running workflows. WCF provides a general framework for building connected systems and defining communication between two endpoints. With WCF LOB Adapter, you can use the consistent WCF API to access the line-of-business systems in the business processes within your environment. WF allows you to model and encapsulate your business logic and process, while WCF provides you with messaging infrastructure that gives you ability to distribute your systems. WF is a lightweight component (compared to BizTalk Orchestration) that runs within your application’s or component’s process.
Note to adapter developers: Workflows will execute asynchronously to the service call, so design appropriately when thinking about returning data from the adapter.
Usage Pattern 4 – Consume adapter in a Web Application
Design Time: In Visual Studio 2005 SP1, use in project templates such as ASP.NET Web Application and ASP.NET Web Site.
According to enterprise architecture guidelines and solution patterns, accessing data from target systems is usually in a separate data access layer. Add Adapter Service Reference Visual Studio Plug-In tool can be used to generate a Common Lanuage Runtime (CLR) WCF Client Proxy to access data from line-of-business target systems.
Usage Pattern 5 – Consume adapter in a Web Service
Design Time: In Visual Studio 2005 SP1, use in project templates such as ASP.NET Web Service, WCF Service and WCF Service Library
In the standard Web Service development cycle, start with either top-down, bottom-up or combination of web service design and use the WCF LOB Adapter to access data from a line-of-business target system. This is especially useful if you are building a Composite Web Service or a workflow using WF that will be deployed as service for integration with other client applications.
If you are –
Building a Web Service (using top-down approach) or
Hosting a workflow as a WCF Service or
Publishing a BizTalk Orchestration as a Web Service
AND there is a need to access data from a line-of-business system within these services, you still need some access mechanism to talk these target system. WCF LOB Adapter can be used to access the data from line-of-business system.
Usage Pattern 6 – Expose the proxy generated from adapter as a Web (WCF) Service hosted in IIS
The WCF LOB Adapter runs ‘in-proc’ in a client process. If there is a need to access the proxy over the internet using SOAP, the proxy class can be surfaced as a WCF service and hosted in a Web Server.
To accomplish this, you need to create a WCF Service Web Site project and add –
1. .Svc File: This should point to the service implementation class. The “proxy” generated from the adapter contains a service interface and classe that implements this interface. This class can be used as the “service implementation” CLR class in .svc. This file functions very similar is very similar to an .asmx file in classic ASMX web service. It gets placed in the virtual diractory under IIS and is used to identify the code behind the service and the class.
2. Web.Config: This will contain the service endpoint information, where the address is where this service will be hosted, binding is one of the HTTP bindings, contract is the interface generated from the adapter and the service implementation points to the class that implements the interface. The client endpoint information is still needed to communicate with the line-of-business. For the client endpoint, the address contains the location of the line-of-business system, binding is the adapter binding and contract is the interface generated from the adapter. The client endpoint is generated by Add Adapter Service Reference Visual Studio Plug-In.
3. Service Interface and CLR Class: Add Adapter Service Reference Visual Studio Plug-In generates these after the adapter consumers has browsed/searched the metadata hierarchy and selected a few methods of choice.
In current release, it takes a few manual steps to configure, host and publish a line-of-business system proxy generated from the adapter as a WCF Service. Also, special consideration is required for passing the line-of-business Client Credentials to the adapter (can be done using WCF behaviors). A future release of WCF LOB Adapter SDK will include tooling to automate these steps.
Usage Pattern 7 – Consume adapter in Microsoft Office SharePoint Server 2007
One of the major ways to connect to the data and existing applications from Office Applications is through the Business Data Catalog (BDC), a new integration feature in Microsoft Office SharePoint Server (MOSS) 2007. It is shared service and it surfaces business data from back-end data and applications without any coding. BDC is a metadata repository that defines business entities like customers, invoices and purchase orders. Once defined, these entities can be used by the clients. The BDC provides built-in support for displaying data from line-of-business (LOB) applications via databases and Web Services.
Until BDC provides native support for WCF (it is scheduled for a later release), the workaround is to follow the Usage Pattern 6 (substitute Basic Profile Intenet Client with BDC) to expose the data from WCF LOB Adapter as a Web Service. BDC can then integrate with this Web Service. The extra data (de) serialization can be avoided if the WCF LOB Adapter binding can be hosted ‘in-proc’ with BDC.
by community-syndication | Jul 8, 2007 | BizTalk Community Blogs via Syndication
Over the times parents have named their kids many
things…but I do feel sorry for this little girl being called Vista.
A father called his daughter Vista….does this mean the son will be called ‘LongHorn’
and who knows about upgrades, boyfriends and remote offsite camping trips.
Wonder no more why so many people change their names over in the US.
Monday’s tidbit.
by community-syndication | Jul 8, 2007 | BizTalk Community Blogs via Syndication
by community-syndication | Jul 8, 2007 | BizTalk Community Blogs via Syndication
I just received my most recent TechNet email from Microsoft, what was the subject?
Virtualization.
Sogeti has a Director in Houston, John Cook,who
is an MVP, in what area? Virtualization.
Now, I have to agree, Virtualization is the best. As I write this I’ve got an
instance of Windows Server 2003 R2 running in the background as a virtual machine
where I’m developing for my current client. I keep VPC’s around from which I
do most of my presentations. It’s great, given.
But what does this craze say about the business of software? With very few exceptions
(SQL Server and BizTalk notably) most enterprises are looking to go virtual for most
of their applications. Why not SQL Server and BizTalk? Because they really
work the hardware, if you will because they are solving computationally difficult
tasks. Web servers can make very complex things simple, but usually they are
not very computationally complex for most enterprises.
I think this points to the fact that hardware is outpacing software and that it is
time for software to discover the next truly big problem which will need such performance
that you wouldn’t think of virtualizing it. What do you think these are?
What problems are the white elephants of enterprises which everywhere, the ones no
one talks about anymore because it is merely accepted that they are “unsolvable”?
by community-syndication | Jul 8, 2007 | BizTalk Community Blogs via Syndication
To complete my Arkansas trip, on July 3rd I spoke to the Northwest
Arkansas .NET User Group and presented my talk “Introduction to C# 3.0”.
While there are not any downloads I can offer for that talk, it is all code made up
on the spot in reaction to questions about the features, I would like to take a moment
to thank them for having me out to speak. Jay Smith, President of the NWADNUG,
was an excellent host and I enjoyed both speaking and hanging out with many of the
members at Applebee’s after the meeting. If you find yourself in Fayetteville AR,
or are ever invited to come speak to this group, you should definitely visit them.
Furthermore Fayetteville itself is a very pretty town, the trip in up I-540 reminds
me what I miss about living somewhere that elevation happens, and there are plenty
of great little shops in the area including one of the better board games shops I’ve
run into in a long while.
by community-syndication | Jul 6, 2007 | BizTalk Community Blogs via Syndication
A while back I built a
sample of how you might make a synchronous call between a Parent Workflow and a Child
Workflow. The OOB InvokeWorkflow Activity is asynchronous, and a number of people
on the workflow forums were interested in how to make this work, so I coded up a quick
and dirty sample which a lot of people have used.
The problem with the sample (and this is a pretty common problem that is very easy
to have with Windows Workflow) is that it didn’t work in the face of persistence.
If the host instance went away, the workflows could persist – but the CallWorkflowService
wouldn’t respond properly because of all its state was kept in local variables. I
knew this was a problem a few months ago, but I need to find a solution (the problem
is non-trivial IMO) and needed to find the time to implement the solution.
You can download the persistence friendly CallWorkflow sample here.
The way I solved the problem is based around the use of DependencyProperty. Dependency
properties are one area of WF that is still fairly mysterious to workflow developers.
Without writing a whole post on DependencyProperty – there are two basic reasons for
the use of DependencyProperty (which is really a simple concept – keeping property
values in a collection in the base class rather than having individual field storage
for each property): first to make serialization more efficient, second to enable easier
data binding between properties on unrelated Activities (known as Activity Binding).
Another interesting feature is the use of attached DependencyProperties. An attached
DependencyProperty can be “attached” to an Activity instance which can be totally
unaware of the property. There are a few interesting usages for this – Dennis talks
about one here,
and I mentioned one in my post
about building a custom WorkflowLoaderService.
Attached DependencyProperties was the way I solved this particular problem as well.
The CallWorkflowService does keep a local cache of the relationship between a child
workflow and the parent workflow, as it needs this information to send a message to
the parent workflow when the child workflow is completed or terminated. At the same
time it builds its local cache of this data, the CallWorkflowService embeds this information
into the child workflow instance by using attached DependencyProperties. The CallWorkflowService
defines two attached DependencyProperties by calling DependencyProperty.RegisterAttached.
One property is for the InstanceId of the parent workflow, the other is for the queue
name on the parent workflow that the results of the child workflow will be sent to.
By embedded this information into the child workflow instance, when a child workflow
persists the data persists with the workflow instance. When the workflow instance
is loaded back into a host – the CallWorkflowService can extract that data from the
instance and rebuild its local cache of mappings between child and parent workflows.
Now – to make this implementation work there were a couple of issues I had to work
around. The first is getting attached DependencyProperties embedded into the child
workflow instances. Now – one way to do this would have been to use DynamicChange.
Inside of the CallWorkflowService’s StartWorkflow method where the child workflow
instances are created using WorkflowRuntime.CreateWorkflow, I could have used the
WorkflowChanges object to make a cloned copy of the child workflow and then embed
the DependencyProperty values into the instance using Activity.SetValue (which is
really DependencyObject.SetValue). In this sample I went to great lengths to use the
most efficient means possible to accomplish my tasks. So instead of using WorkflowChanges,
I created a custom WorkflowLoaderService (again for other reasons for doing this see
my earlier
blog post). By creating a custom WorkflowLoaderService I could embed the DependencyProperty
values at workflow creation time – avoiding the overhead of DynamicChange.
The next issue of course was how to communicate between the CallWorkflowService and
the WorkflowLoaderService. Since the call to WorkflowRuntime.CreateWorkflow doesn’t
allow non-Activity parameters to be passed (and the parameters themselves are not
passed to the WorkflowLoaderService) I had to come up with an out-of-band way to pass
data to the custom WorkflowLoaderService so it would be able to detect when to place
these DependencyProperty values into a child workflow (since not all workflows will
be child workflows – some will be parent workflows and some presumable wouldn’t be
a child or a parent – just standalone workflows in this host). To pass these two pieces
of data (the parent’s InstanceId and the queue name) I went with CallContext. CallContext
is a useful way to pass data between two methods in the same logical call stack (see
TODO for more information about CallContext).
So the CallWorkflowService puts the two needed values into CallContext, and the custom
WorkflowLoaderService picks them up from the CallContext (if they are there) and calls
Activity.SetValue to embed the data inside of the workflow instance (again this is
to make sure the information is persisted if and when the child workflow were to persist).
So the first half of the problem is accomplished – the parent’s instance id and the
queue name become embedded inside of the child workflow using attached DependencyProperties
by using CallContext to pass the data between the CallWorkflowService and the custom
WorkflowLoaderService. Now I needed to solve the second part of the problem – which
is to extract the data from instances which are loaded into a host from the persistence
store.
My first plan was to build a custom WorkflowPersistenceService and wrap whatever WorkflowPersistenceService
the host was originally going to use (like the SqlWorkflowPersistenceService). The
rationale I had for try to make this work was again to make this sample as efficient
as possible. When an Activity instance is reloaded by a WorkflowPersistenceService,
the WorkflowPersistenceService has access to the raw Activity instance (not just through
the WorkflowInstance object).
The other option isn’t my preferred option because it involved calling WorkflowInstance.GetWorkflowDefinition.
I’ve blogged about GetWorkflowDefinition before in terms of what it is good for and
what it shouldn’t be used for. The reason it isn’t my preferred option doesn’t have
anything to do with those issues – but rather with the expense of calling GetWorkflowDefinition.
GetWorkflowDefinition makes a cloned copy of the Workflow. This means the Activity
instance is serialized into a memory stream and then deserialized into a new object
instance (this is what Activity.Clone does). This can be an expensive operation for
a medium to large workflow. Obviously GetWorkflowDefinition is a very useful API and
you can use it, but it should be used sparingly.
Of course you might be able to tell I ended up using GetWorkflowDefinition. The problem
with my first plan was that you can’t use a container pattern with any of the well-known
Workflow Services like the TrackingService, WorkflowPersistenceService, or WorkflowLoaderService.
The reason you can’t is because the methods you’d need to call on the contained instances
are marked “protected internal”. This means a derived instance can’t call the methods
necessary to delegate functionality to the contained instance. The WorkflowRuntime
of course can call the methods since they are marked “internal” and the WorkflowRuntime
is in the same assembly as the base class definitions.
So to solve the second half of the problem the CallWorkflowService subscribes to the
WorkflowRuntime.WorkflowLoaded event. When a workflow instance is loaded it checks
to see if the two DependencyProperties are found inside of the loaded instance. When
the properties are found, that indicates to the CallWorkflowService that this is indeed
a child workflow, and it uses this information to rebuild its local cache mapping
between the parent and the child.
When a Workflow completes or terminates the CallWorkflowService looks to see if the
instance is one that it is interested in (i.e. if it is a child workflow). If it is
a child workflow, then it extracts the parent id and the queue name from the instance.
Now – in the case of the WorkflowCompleted event, I didn’t mind using the WorkflowDefintion
property on the WorkflowCompleted event argument – because the WorkflowRuntime pre-populates
the WorkflowDefintion so my code isn’t calling GetWorkflowDefinition again (i.e. it
isn’t adding additional overhead).
That’s pretty much it – if you missed it earlier – feel free to download the persistence
friendly CallWorkflow sample here (I’ve
replaced the earlier sample with this one – the earlier sample I named HideChildWorkflow
– because it also shows how you can use a composite child activity and hide the designer
by using a custom designer). Note – to run this sample you’ll need to create a database
named CallWorkflowPersistence and configure the SqlWorkflowPersistence tables and
stored procs.
by community-syndication | Jul 5, 2007 | BizTalk Community Blogs via Syndication
Nas is looking for feedback for the name for the new designer driven WPF/ Silverlight User Group that she is setting up in Wellington.
I suggested
ZamDes (XAML + Designer), what do you think?
Who said I’m not a designer…
Add your suggestions to her blog…
Hmmm now we just need to clone Nas for Auckland, ChCh and other cities around New Zealand!
Now who owns http://zamdes.com 😉
by community-syndication | Jul 5, 2007 | BizTalk Community Blogs via Syndication
In June, we released a new community release build of the Microsoft ESB Guidance on the ESB Guidance community site. In addition to fixes and new samples & guidance, this release includes new and augmented features such as WS-MetadataExchange, WCF adapter integration, UDDI publishing, enhanced ESB portal, third party SOA management and governance integration and more.
For those interested to learn more, make sure to read Marty Wasznicky’s latest blog postings. You’ll find a lot of very helpful information there.
Regards,
Marjan
by community-syndication | Jul 5, 2007 | BizTalk Community Blogs via Syndication
This is a fairly common scenario after Windows 2003 SP1 (or greater) is installed, so I thought I better put in my two cents
Scenario: BizTalk seems to lose connectivity to the MsgBox (and all other databases on that SQL instance)
Problem: The operating system (w2k3 sp1) running the SQL server instance is misinterpreting the heavy TCPIP connection traffic from the BizTalk App server as a Denial of Service (DOS) attack.
Clarification: This is an operating system level issue. This is not BizTalk or SQL per se (though they are common victims of this security feature). This is a security feature for the OS that affects how the OS interprets large amounts of incoming connections from individual clients.
Factors:
1. Windows Server 2003 SP1 (or higher) is installed on the SQL server hosting the BizTalk DBs
2. SynAttackProtect is still set to “1” on the SQL server
3. Concurrent TCPIP connection requests from a specific BizTalk app server exceeds the critical threshold (Sorry, don’t know what that threshold is!)
Diagnosing:
- Look for the following event entries:
Event Type: Error
Event Source: BizTalk Server 2004
Event Category: (1)
Event ID: 6913
Computer: %ServerNameHere%
Description: SQLServer, BizTalkMsgBoxDb, [DBNETLIB][ConnectionWrite (send()).]General network error. Check your network documentation..
Event Type: Warning
Event Source: BizTalk Server 2004
Event Category: (1)
Event ID: 5410
Computer: %ServerNameHere%
Description: An error has occurred that requires the BizTalk service to terminate. The most common causes are an unexpected out of memory error and an inability to connect or a loss of connectivity to one of the BizTalk databases. The service will shutdown and auto-restart in 1 minute. If the problematic database remains unavailable, this cycle will repeat.
Error message: [DBNETLIB][ConnectionWrite (send()).]General network error. Check your network documentation.
Error source:
BizTalk host name: BizTalkHost
BizTalk Windows service name: BTSSvc$BizTalkHost.
Fixes:
1. Set the SynAttackProtect registry setting as described in http://support.microsoft.com/kb/899599
2. ALSO take a look at the Group policy for that SQL server to be sure that the Group Policy does not periodically UNDO the setting change that you did in step 1. I have been in the situation where I fixed the issue, but then the GP Update or reboot undid the fix! (Put the server in a separate OU if you have to, but make sure you isolate the box from policies that would reset this registry key)
Limitations
1. I don’t know how to disable this feature for a specific set of clients (i.e. SynAttackProtect is off for the BizTalk app servers but remains on for other servers). The setting seems to be at the protocol level so I wouldn’t even know where to start looking for network set definition here.
Is there something that I can do to make this blog more helpful to you? I welcome your feedback!
by community-syndication | Jul 5, 2007 | BizTalk Community Blogs via Syndication
This is a fairly common scenario after Windows 2003 SP1 (or greater) is installed, so I thought I better put in my two cents
Scenario: BizTalk seems to lose connectivity to the MsgBox (and all other databases on that SQL instance)
Problem: The operating system (w2k3 sp1) running the SQL server instance is misinterpreting the heavy TCPIP connection traffic from the BizTalk App server as a Denial of Service (DOS) attack.
Clarification: This is an operating system level issue. This is not BizTalk or SQL per se (though they are common victims of this security feature). This is a security feature for the OS that affects how the OS interprets large amounts of incoming connections from individual clients.
Factors:
1. Windows Server 2003 SP1 (or higher) is installed on the SQL server hosting the BizTalk DBs
2. SynAttackProtect is still set to “1” on the SQL server
3. Concurrent TCPIP connection requests from a specific BizTalk app server exceeds the critical threshold (Sorry, don’t know what that threshold is!)
Diagnosing:
- Look for the following event entries:
Event Type: Error
Event Source: BizTalk Server 2004
Event Category: (1)
Event ID: 6913
Computer: %ServerNameHere%
Description: SQLServer, BizTalkMsgBoxDb, [DBNETLIB][ConnectionWrite (send()).]General network error. Check your network documentation..
Event Type: Warning
Event Source: BizTalk Server 2004
Event Category: (1)
Event ID: 5410
Computer: %ServerNameHere%
Description: An error has occurred that requires the BizTalk service to terminate. The most common causes are an unexpected out of memory error and an inability to connect or a loss of connectivity to one of the BizTalk databases. The service will shutdown and auto-restart in 1 minute. If the problematic database remains unavailable, this cycle will repeat.
Error message: [DBNETLIB][ConnectionWrite (send()).]General network error. Check your network documentation.
Error source:
BizTalk host name: BizTalkHost
BizTalk Windows service name: BTSSvc$BizTalkHost.
Fixes:
1. Set the SynAttackProtect registry setting as described in http://support.microsoft.com/kb/899599
2. ALSO take a look at the Group policy for that SQL server to be sure that the Group Policy does not periodically UNDO the setting change that you did in step 1. I have been in the situation where I fixed the issue, but then the GP Update or reboot undid the fix! (Put the server in a separate OU if you have to, but make sure you isolate the box from policies that would reset this registry key)
Limitations
1. I don’t know how to disable this feature for a specific set of clients (i.e. SynAttackProtect is off for the BizTalk app servers but remains on for other servers). The setting seems to be at the protocol level so I wouldn’t even know where to start looking for network set definition here.
Is there something that I can do to make this blog more helpful to you? I welcome your feedback!
