I had to change a username from mabri0 to svc_biztalk within the DB2 adapter. After I did this the DB2 adapter failed to connect anymore. I tried to test the connection using the Data Access Tool. It gave and error when trying to add the username and password, namely "The username is invalid or contains […]
Blog Post by: mbrimble
Last week I read Cloudonomics by Joe Weinman and found it to be the most complete, well-told explanation of cloud computing’s value proposition that I’ve ever read. Besides the content itself, I was blown away by the depth of research and deft use of analogies that Weinman used to state his case. The majority of […]
Blog Post by: Richard Seroter
Working with an integration to the ERP system Dynamic NAV from Microsoft I had a request to be able to put large text into a blob (image) field as Dynamic NAV in the version that I was integrating to couldn’t create large (over 250 characters) in other way than in a blob field.
It is easy to put text into the field. You just do a cast to image field like this:
declare @longtext varchar(1000)
set @longtext = ‘very long text and so on….’
update tableX set imagetext = cast(@longtext as image)
where id = 1
If you want to extract the text again from the field is a bit more complicated, but isn’t that hard once you know it. You first have to convert it to varbinary and then you can convert it to varchar. Like this:
select convert(varchar(1000), convert(varbinary(1000),imagetext) from firstdb.dbo.tableX where id = 1
A weird thing that I experienced working in SQL Server Management Studio was if a ran this query when I am working (like “use firstdb”) in the database, the local special characters was returned without any problems. If I instead was in the master database (like “use master”) and executed the query it return some different characters when it came to the locale special characters. As far as I can tell the collation was the same in both the databases.
From that point on he developed complex live financial data processing applications that integrated with SAP, and .Net web services. Finally he learned about deployment of applications and supporting them. He is basically an all-round BizTalk professional now like many of us.
When for example a send port fails in BizTalk, both the message and the service instance show up in the BizTalk Administration Console as being suspended. When the destination is wrong you can change it and resume the message but when the ESB Management Portal is used to monitor the behavior of applications, you cannot resume a message because you can only resubmit a message to an on-ramp. The resubmitted message does not contain any of the context properties of the original message. But is it possible to change the ESB Management Portal a bit so failed messages can be resumed from the ESB Portal?
The following endpoints are suitable for resubmission:
The ESB.ItineraryServices ASMX on-ramp expects an ESB itinerary in the SOAP header. In order to test if the ASMX on-ramp accepts also a partially processed itinerary I used the Itinerary Test Client to submit a message and a partially processed itinerary to this on-ramp.
First I’ve created an itinerary with 2 messaging services. The Transform Service transforms the incoming message but he Routing Service has a resolver that has a wrong destination folder.
The state of the services in the itinerary are all “Pending” when the itinerary is exported to a file.
The created itinerary can be tested with the Itinerary Test Client that is located in the ESB Toolkit sample applications.
The Esb.Itinerary.Test.exe tool is located in \Source\Samples\Itinerary\Source\ESB.Itinerary.Test\bin\Debug
When the “Enable routing for failed messages” check box in the Send Port is selected, the failed message is picked up by the ESB Management Portal.
The failed itinerary is saved in the “ItineraryHeader” context property off the message.
All the context properties of a failed message are saved in the ContextProperty table in the EsbExceptionDb database. I’ve extracted the itinerary from the database and saved it to a .XML file.
The error occurred in the send port and because a send port is also a service in an itinerary, the attributes in the ServiceInstance element are set to the “DynamicPort” send port.
To make it work I had to change the attributes in the ServiceInstance element and set it to the ESB.Services.Routing service because Dynamic Send Ports do not contain a fixed destination address, only a pipeline.
When the altered itinerary is send to the ESB.ItineraryServices ASMX on-ramp with Itinerary Test Client, the ESB.Services.Routing service is skipped because his state is already “Complete”
So it is possible to resubmit a processed itinerary to an Onramp! You only have to change the ESB Management Portal a bit to make it work,. ( –;
Happy Coding!
Normal
0
false
false
false
EN-AU
X-NONE
X-NONE
MicrosoftInternetExplorer4
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at System.ServiceModel.Channels.IRequestChannel.EndRequest(IAsyncResult result)
at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfClient`2.RequestCallback(IAsyncResult result)
<machineSettings maxTimeout=”01:10:00″ />
</system.transactions>
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:”Table Normal”;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:””;
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin-top:0cm;
mso-para-margin-right:0cm;
mso-para-margin-bottom:10.0pt;
mso-para-margin-left:0cm;
line-height:115%;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:”Calibri”,”sans-serif”;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:”Times New Roman”;
mso-bidi-theme-font:minor-bidi;
mso-fareast-language:EN-US;}
We have a 2 day BizTalk Server 2010 Administrator course scheduled for the 19th & 20th of November in Melbourne. Register
The BizTalk Server 2010 Administrator Training is an update version of the existing BizTalk training for 2010. The course shows you how to deploy and manage BizTalk and BizTalk applications in a production environment and is targeted at beginning BizTalk Server administrator or support personnel.
Any question or discuss your BizTalk training needs please contact me
We have a 5 day BizTalk Server 2010 Developer course scheduled for the 12th – 16th of November in Melbourne. Register
The BizTalk Server 2010 Developer Training is an update version of the existing BizTalk training that now includes WCF send and receive adapter, a BizTalk Patterns module (correlation, sequential convoy and parallel convoy) and optional EDI components. The course is targeted at beginning BizTalk developer or developers that want to bring their skills up to 2010.
Any question or discuss your BizTalk training needs please contact me
For debugging, it is neccessary to attach the BizTalk host instance process to Visual Studio. However, if you have multple host instances, you cant tell which one is which. I have found a PS script which gives you the process Ids of multiple host instances. TASKLIST /FI “USERNAME ne NT AUTHORITYSYSTEM” /FI “IMAGENAME eq BTSNTSvc.exe” […]
Blog Post by: DipeshA
Published by: Bill Chesnut
Recently at our Mexia Code Camp the 2 days before TechEd Australia on the Gold Coast I had a chance to look at the recently released Service Bus 1.0 Beta for Windows Server. Having spent a fair bit of time working with the Azure Service Bus I am interested in how the on-premises version compares and to my relief it is a very close implementation.
The differences that I found were around the authentication and the addressing, the Windows Server version ships with it own STS for authentication using your windows credentials so that it can have no dependencies on the Azure ACS. The addressing of the queues differ by the fact that you are talking to a windows server in your infrastructure, so instead of the Azure. Azure uses a method of .servicebus.windows.net, on-premises you end up with .<your domain (options)/ these differences are support by a modified Microsoft.ServiceBus.dll version 1.6 that is part of the beta install.
So now on the a performance comparison, I typically don’t put much stock in performance testing of beta version by I was interested to see just a rough estimate of the performance. One of the 1st issues that I ran into was that my previous Azure service bus performance testing was dong with BizTalk, but the WCF netMessagingTransport and specifically the transportClientEndpointBehavior does not support the windows sts authentication. To overcome this missing authentication support in the beta I modified the BizTalk Service Bus adapter that I am currently working on to support the on-premises beta, the changes were minimal and really only effected the connection establishment part of the adapter.
Now what kind of numbers did I get, so my previous testing with the Azure Service Bus topics was bases on sending 600 messages to a topic with 600 subscriptions, so I replicated the same configuration in my on-premises test, luckily the utility code that I had written for creating the 600 subscription work with minor changes to the the connection code. One of the 1st things that I tested was Azure Service Bus has a limit of 100 concurrent connections, was that the same for windows server beta, no it seem there is no limit to the number of connections to an individual queue, topic or subscription. Running the same test as with Azure, I found that Azure was taking 15 seconds to send the 600 message to a topic with 600 subscriptions and the on-premises beta was taking 30 seconds, which is not as bad as it seems, since my on-premises implementation is running on a single virtual machine with SQL and BizTalk on the same virtual. Which indicates that what most people think is the biggest limiting factor for Azure is the latency to the Azure data centre is not the limiting factor, processing the filters for 600 subscriptions on a single topic seem to be more limiting than the connection latency.
Next steps, The overall design of the windows server implementation of service bus is bases on a farm model, with my test environment I had a single server farm, so I am planning to create a 4 virtual machine on-premises service bus farm to see how spreading the load across multiple virtual machines help the overall through put.
I think the on-premises implementation of service bus offers a great addition to our integration toolkit and can fill the gaps when the cloud is not the right solution for your integration solutions.