by community-syndication | Sep 6, 2006 | BizTalk Community Blogs via Syndication
I was recently asked if there was an easy way to invoke WSE 3.0 Web Services from a Windows Workflow Foundation (WF) workflow. One of the key features that make WF different from other Workflow engines is the combination of declarative language (XAML) and imperative language (C#-VB.NET). Having the capability to extend the workflow using .NET code makes it possible to invoke WSE 3.0 Web Services in the same way as a classic .NET client application. The key is to apply the client policy to the proxy class used by the InvokeWebService activity.
WF provide the InvokeWebService activity that allows invoking operations in HTTP-hosted Web Services as a default; however this activity does not provide any out of the box support for WS-* protocols. Using the ProxyClass and UserData properties of the InvokeWebService activity we can implement a generic technique in order to invoke WSE 3.0 Web Services. The ProxyClass property contains the proxy type used to communicate with the Web Service. The UserData property contains an IDictionary with data that can be used to extend/customize the functionality of the InvokeWebService activity.
Let’s view the following Web Service example step by step.
Step One: Web Service
|
[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
[Policy("servicePolicy")]
public class MathService : System.Web.Services.WebService
{
public MathService () {
//Uncomment the following line if using designed components
//InitializeComponent();
}
[WebMethod]
public int Add(int param1, int param2)
{
return param1 + param2;
}
}
|
Step two. The “servicePolicy” policy that implements an Anonymous over certificate scenario.
|
<policies xmlns="http://schemas.microsoft.com/wse/2005/06/policy">
<extensions>
<extension name="anonymousForCertificateSecurity" type="Microsoft.Web.Services3.Design.AnonymousForCertificateAssertion, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<extension name="x509" type="Microsoft.Web.Services3.Design.X509TokenProvider, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<extension name="requireActionHeader" type="Microsoft.Web.Services3.Design.RequireActionHeaderAssertion, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</extensions>
<policy name="servicePolicy">
<anonymousForCertificateSecurity establishSecurityContext="false" renewExpiredSecurityContext="true" requireSignatureConfirmation="false" messageProtectionOrder="SignBeforeEncrypt" requireDerivedKeys="true" ttlInSeconds="300">
<serviceToken>
<x509 storeLocation="LocalMachine" storeName="My" findValue="CN=tc2003s" findType="FindBySubjectDistinguishedName" />
</serviceToken>
<protection>
<request signatureOptions="IncludeAddressing, IncludeTimestamp, IncludeSoapBody" encryptBody="true" />
<response signatureOptions="IncludeAddressing, IncludeTimestamp, IncludeSoapBody" encryptBody="true" />
<fault signatureOptions="IncludeAddressing, IncludeTimestamp, IncludeSoapBody" encryptBody="false" />
</protection>
</anonymousForCertificateSecurity>
<requireActionHeader />
</policy>
</policies>
|
Step three. How to invoke this Web Service from WF we need to change the base type of the reference proxy class to Microsoft.Web.Services3.WebServiceClientProtocol.
|
[System.CodeDom.Compiler.GeneratedCodeAttribute("wsdl", "2.0.50727.42")]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute("code")]
[System.Web.Services.WebServiceBindingAttribute(Name = "ServiceSoap", Namespace = "http://tempuri.org/")]
public partial class Service : Microsoft.Web.Services3.WebServicesClientProtocol
{
Code here…
}
|
Step four. We need to configure the client policy required to interface with the Web Service.
|
<policies xmlns="http://schemas.microsoft.com/wse/2005/06/policy">
<extensions>
<extension name="anonymousForCertificateSecurity" type="Microsoft.Web.Services3.Design.AnonymousForCertificateAssertion, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<extension name="x509" type="Microsoft.Web.Services3.Design.X509TokenProvider, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<extension name="requireActionHeader" type="Microsoft.Web.Services3.Design.RequireActionHeaderAssertion, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</extensions>
<policy name="clientPolicy">
<anonymousForCertificateSecurity establishSecurityContext="false" renewExpiredSecurityContext="true" requireSignatureConfirmation="false" messageProtectionOrder="SignBeforeEncrypt" requireDerivedKeys="true" ttlInSeconds="300">
<serviceToken>
<x509 storeLocation="CurrentUser" storeName="AddressBook" findValue="CN=tc2003s" findType="FindBySubjectDistinguishedName" />
</serviceToken>
<protection>
<request signatureOptions="IncludeAddressing, IncludeTimestamp, IncludeSoapBody" encryptBody="true" />
<response signatureOptions="IncludeAddressing, IncludeTimestamp, IncludeSoapBody" encryptBody="true" />
<fault signatureOptions="IncludeAddressing, IncludeTimestamp, IncludeSoapBody" encryptBody="false" />
</protection>
</anonymousForCertificateSecurity>
<requireActionHeader />
</policy>
</policies>
|
Step five. Using the UserData property we set the name of the client policy that needs to be applied to the proxy. We are using a CodeActivity executed before the InvokeWebService activity.
|
private void codeActivity1_ExecuteCode(object sender, EventArgs e)
{
invokeWebServiceActivity1.UserData.Add("WSPolicy", "clientPolicy");
…
}
|
Step six. Our final step is to use the InvokingEvent of the InvokeWebService activity to set the client policy to the Web Service proxy.
|
private void invokeWebServiceActivity1_Invoking(object sender, InvokeWebServiceEventArgs e)
{
string policy= (string)((InvokeWebServiceActivity)sender).UserData["WSPolicy"];
((WebServicesClientProtocol)e.WebServiceProxy).SetPolicy(policy);
}
|
This generic technique can be applied to different turnkey security scenarios implemented in WSE 3.0. The creation of custom WF activities may be required for more complex interactions (like multi-transport). The code for this example is available at the WF community site.
by community-syndication | Sep 6, 2006 | BizTalk Community Blogs via Syndication
There’s a confusing symptom when you use “Ordered Delivery” to avoid SQL deadlock.
Complete answer that I found on newsgroup.
by community-syndication | Sep 5, 2006 | BizTalk Community Blogs via Syndication
A co worker asked me how she could take dlls that were developed by a third party and use them in BizTalk; that requires that they be compiled as strong named assemblies (which they weren’t).
This can be done by using the Type Library Importer. An example is here on how to use Tlbimp.exe.
by community-syndication | Sep 5, 2006 | BizTalk Community Blogs via Syndication
BizTalk’s September theme on TechNet is performance and there have been several new whitepapers created and published as part of this theme. BizTalk Server 2006: Managing a Successful Performance Lab was a collaborative effort between the BizTalk TAP team, Product Team, Ranger Team, and MCS, and an attempt to establish a canonical process around managing a performance lab that can assist the field, partners, and end customers tackling such an engagement. Inevitably, we hope this will lead to more successful implementations of BizTalk in the future:
Part of every application’s pre-production testing should include performance and stress testing. You should know the limits of your platform and your applications with certainty prior to ever receiving or sending a live message in production use.
Performance and stress testing can also intersect with capacity planning. Understanding upfront what type of hardware you’ll require and how much will be critical for your business. Also, if your company has very strict requirements for volume or latency with constraints on hardware, proving that the system can meet the required goals with expected hardware will be key.
This document exists to provide some general guidance around approaching performance labs with BizTalk Server 2006. For specifics, we have made reference to correlated documents that already exist on the web or in the product documentation for additional assistance.
Another interesting read is the BizTalk Server 2006 Comparative Adapter Study whitepaper which describes the results of a comparative adapter study-a set of tests that compared each adapter that ships with Microsoft BizTalk Server 2006 against its BizTalk Server 2004 SP1 counterpart under identical conditions.
Happy reading!
by community-syndication | Sep 5, 2006 | BizTalk Community Blogs via Syndication
BizTalk’s September theme on TechNet is performance and there have been several new whitepapers created and published as part of this theme. BizTalk Server 2006: Managing a Successful Performance Lab was a collaborative effort between the BizTalk TAP team, Product Team, Ranger Team, and MCS, and an attempt to establish a canonical process around managing a performance lab that can assist the field, partners, and end customers tackling such an engagement. Inevitably, we hope this will lead to more successful implementations of BizTalk in the future:
Part of every application’s pre-production testing should include performance and stress testing. You should know the limits of your platform and your applications with certainty prior to ever receiving or sending a live message in production use.
Performance and stress testing can also intersect with capacity planning. Understanding upfront what type of hardware you’ll require and how much will be critical for your business. Also, if your company has very strict requirements for volume or latency with constraints on hardware, proving that the system can meet the required goals with expected hardware will be key.
This document exists to provide some general guidance around approaching performance labs with BizTalk Server 2006. For specifics, we have made reference to correlated documents that already exist on the web or in the product documentation for additional assistance.
Another interesting read is the BizTalk Server 2006 Comparative Adapter Study whitepaper which describes the results of a comparative adapter study-a set of tests that compared each adapter that ships with Microsoft BizTalk Server 2006 against its BizTalk Server 2004 SP1 counterpart under identical conditions.
Happy reading!
by community-syndication | Sep 5, 2006 | BizTalk Community Blogs via Syndication
I put the code for my Atlas-based WF designer here on my site so you can try it out
without having to download and install everything. Link is http://www.masteringbiztalk.com/atlasworkflowdesigner/
by community-syndication | Sep 5, 2006 | BizTalk Community Blogs via Syndication
In this case, you should check whether “Character width in target system”
is unicode or not. If it’s unicode, you should set code page of “SAP
Transport Properties” in Biztalk Admin console to either 4102 which
is SAP defined UTF-8 code page.
Then how can you test connection between SAP and Biztalk?
RFC Destination connection test
1. launch SAPGUI.
2. login.
3. excute transaction SM59(Display and maintain RFC destinations)
4. TCP/IP Connections
4.1. pick RFC destination.
5. go to special options.
6. change “Character Width in Target System”.
6.1. either Non-Unicode or Unicode.
7. test connection .
8. Unicode connection.
Configuration in Biztalk Admin Console
Non-Unicode:
1. Biztalk Administration
2. Receive PipeLine
3. Sap Transport Properties
4. Sap Authorization
4.1. code page = 0(default)
4.2. Biztalk code page = 65001(this can be varied for own situations)
Unicode:
1. Biztalk Administration
2. Receive PipeLine
3. Sap Transport Properties
4. Sap Authorization
4.1. code page = 4102
4.2. Biztalk code page = 65001
If codepage you set in Biztalk Admin Console, connection will be failed and
put error message like this.
Target system not reached
If codepage is correct,
Target is a unicode system (char.size 2)
Since char size is 2 by now, you should make sure “Count Positions in
Bytes” property for SAP schema has set to “No”. If this is “Yes”, Biztalk
will count character by byte, if not, by count of chararcters.
Code Page
SAP Defined
—————
4102 : UTF-8
4103 : UTF-16
Non-Unicode
by community-syndication | Sep 4, 2006 | BizTalk Community Blogs via Syndication
I’ve just uploaded an updated version of my FixEncoding custom
pipeline component for BizTalk 2006 (an update for the BizTalk 2004 version is in
the works); you can download it from here.
This update is about making the component useful in Send pipelines. The original version
only set the Charset property of the Body part of the message, which is used by the
Xml and Flat File disassemblers as one possible way to infer the encoding of an incoming
message when probing and disassembling it, and that works fine.
However, send pipelines work in a different way: Both the Flat File and Xml Assembler
components will ignore the Body Part’s Charset property value, and instead will use
the encoding specified in the component properties. The problem with this is that
the list of encodings to choose from in the Pipeline Designer for both components
is severely limited, even though the underlying .NET encoding facilities (which in
turn are partially based on the built-in Operating System facilities) support quite
a bit more.
My FixEncoding component, however, didn’t have that issue and would allow you to choose
any encoding supported by .NET and the Operating System with no problem. However,
since it only sets the Body Part’s Charset property, trying to use it in a send pipeline
wasn’t very useful.
Both the Flat File and Xml Assembler components do support another way of selecting
the desired component: using the XMLNorm.TargetCharset context property of the message
being sent. You can usually set this directly from an orchestration when creating
the message, but this is inconvinient, and not very reusable. Besides, this really
is the kind of thing that is much cleanly done at the pipeline level.
This updated version of the FixEncoding component now contains a second pipeline component:
The SetEncodingComponent. It works just like the FixEncoding component except that
it’s for use in Send Pipelines and it writes the XMLNorm.TargetCharset property to
the message context. You should use it in the Pre-Assemble stage of any send pipeline,
and remember to set the TargetCharset of any assembler component to “(None)” so it
doesn’t override the encoding you choose on the SetEncoding component
Hope you find it useful!
by community-syndication | Sep 4, 2006 | BizTalk Community Blogs via Syndication
If you are interested to know how to web-host InfoPath forms this article describe the required steps in details.
by community-syndication | Sep 4, 2006 | BizTalk Community Blogs via Syndication
While working with direct Message Box binding I became stumped with the following error:
error X2186: identifier ‘VALIDATION_COMPLETE’ does not exist in ‘TrackOrderMessage’; are you missing an assembly reference?
error X2007: cannot find symbol ‘VALIDATION_COMPLETE’
error X2163: an ‘activate’ predicate rvalue must be a string, character, boolean or numeric literal
error X2104: illegal ‘activate’ predicate
The resulting fix? wrap your […]
