If I need to build a specialized web app to be able to terminate messages processed by specific send ports, WMI is one option. Are there others? and are there pros/cons to each approach?
You should be able to terminate messages programmatically by referencing the Microsoft.BizTalk.Operations.dll assembly. That will allow you to use the TerminateInstance method of the BizTalkOperations Class, which allows you to reference a remote BizTalk instance (using this constructor) without enabling remote WMI administrative access.
You may also need to reference Microsoft.BizTalk.Pipeline.dll in Visual Studio to get IntelliSense to work.
The BizTalk SDK includes a sample app that you can review, as well, to see how to look up a message instance, which you'll need for the parameter to the TerminateInstance method:
http://msdn.microsoft.com/en-us/library/gg163868
For example:
BizTalkOperations _operations = new BizTalkOperations()
IEnumerable messages = _operations.GetMessages();
foreach (BizTalkMessage msg in messages)
…
Have you considered the "/null" Send Port Adapter? This allows you to send messages to a "null" port, where they effectively disappear. Source code can be found here, although it hasn't been updated since BizTalk 2006 R2.
If this isn't relevant to what you are trying to achieve, maybe some additional information regarding the use case would help.
Related
All BizTalk 2010 applications on one server stopped working and creating same message:
Routing Failure Report for "Routing Failure Report for "[port-name-here]"
This service instance exists to help debug routing failures for instance "{B79F1529-4796-4CE3-A749-4FA8890A7601}". The context of the message associated with this instance contains all the promoted properties at the time of the routing failure.
They are working well on other servers.
What could cause this problem and what would be best way to fix it ?
UPDATE:There was some king of database cleaning script was executed on BizTalk database. Is there way to validate if there is issue into BizTalk database ?
One possible solution is to reinstall BizTalk application , but I want to make learning experience from it and figure out how to troubleshoot such problems.
It seems like no Subscribers are being found for the message.
Please make sure that the subscribing Send port or the Orchestration are enabled and their corresponding host instances are in enabled mode as well.
Also, if the Send ports are using any context property filters to subscribe to the message, make sure that the filter is correct and the context property values for the received message is correct.
I am new to BizTalk development. I have an existing SOAP web service, which has around 50 different operations. I want to connect this service to another application, but use the BizTalk server as an intermediary in this communication. So service and application should not know each other directly, BizTalk should be able to log all messages going through etc etc.
What is the best approach to make this work in BizTalk Server 2013?
So far I tried to create a new BizTalk Application and import the SOAP web service there. Then however it seems that I need to create around 50 different orchestrations, each one just mapping the incoming message in BizTalk to the external service for each service operation. This seems very cumbersome. Also publishing all those orchestrations becomes painful, as BizTalk cannot merge those into a single endpoint again. Ideally I would like to publish a single endpoint for BizTalk server on IIS that is using the exact same WSDL as the target SOAP service, ideally without having to create any orchestrations at all. Is this possible?
Thanks!
So, yes, but...what you want is absolutely doable but there would be lots of answers for that. Once you learn how things in BizTalk are actually working, it's obvious how to do this.
For example, a single Receive Location (IIS endpoint) can receive any number of request types provided they are the same protocol/format, SOAP, REST/JSON for example. The only difference in the IIS site is any metadata, so just don't publish that. The Message differentiation is done in the Pipelines just like any other BizTalk Message.
You don't really need Orchestrations for Maps, you can apply those at the Port Level provided it's a 1-1 relationship between the SOAP call and Map.
Please try a few things. I'll become clear. You can always come back for any specific issues.
I'm working on a web service that uses ASP.NET security model (i.e. with AspNetCompatibilityRequirements set to allowed). Like many others, I got an error saying the Anonymous access is required because the mexHttpBinding requires it and the only way to get around it is to remove the mex endpoint from each service as described here:
WCF - Windows authentication - Security settings require Anonymous
I thought by removing mex endpoint I will no longer able to generate WSDL or add a reference to the service from Visual Studio but to my surprise everything still works. I quickly googled the "mex binding" but most web sites just say it's for "Metadata Exchange" without going into too much detail on what it actually does.
Can anyone tell me what's the side effect of removing the mex binding?
If your WCF service does not expose service metadata, you cannot add a service reference to it, neither from within Visual Studio (Add Service Reference), nor will another client be able to interrogate your service for its methods and the data it needs.
Removing Metadata Exchange (mex) basically renders the service "invisible", almost - a potential caller must find out some other way (e.g. by being supplied with a WSDL file, or by getting a class library assembly with a client he can use) about what the service can do, and how.
This might be okay for high risk environment, but most of the time, being able to interrogate the service and have it describe itself via metadata is something you want to have enabled. That's really one of the main advantages of a SOAP based service - by virtue of metadata, it can describe itself, its operations, all the data structures needed. That feature is used to make it really easy to call that service - you just point to the mex endpoint, and you can find out all you need to know about that service.
Without the metadata exchange, you won't be able to use svcutil.exe to automatically generate the proxy classes.
How do you capture errors that happen on client side when building RIA apps using Flex and Silverlight? What are the common practices? I have seen some asynch js calls to a web service implemented but would like to know how the community is dealing with it.
First, I use client side logging all of the times.
the way I handle it depends on the entire application.
if I use an AMF gateway then there's a call for an application error, with every error that occurs the server is notified, in the server side a bug is open in BugZilla (this is what we use, you can use any other hook you want).
If I use a web-service based application then there's a web-service call for a client error.
one would say you shouldn't sample the server with every error, I disagree with this comment because an error in the client side is rare, it goes thorough QA before being released to the client so I want to know immediately on every error the client is experiencing.
In Silverlight I like to use a WebClient to log back to a web service somewhere -- you can do this directly in the Silverlight application without calling out to JavaScript.
To catch exceptions that are fired when your code isn't on the stack, you can use the Application.UnhandledException event.
I've used the same approach as Avi Tzurel - you need to know on the server side when an error appeared in the Flex client. If you want to collect more data (all the log messages, warnings) I would use an internal buffer and I will flush it asynchronously.
Anyway, you need to take into consideration if your customers are ok with this approach..maybe you need their agreement before sending the error message to the server.
I basically percolate all errors to the top, and capture them in the unhandled exception. I display a friendly message to the user. However, throughout my application I implement an ILogger interface. This interface can be initialized with various levels and handles any messaging. You can set it up so the user can add an init param to determine whether or not to transmit the errors to a service, and I typically have the logger write the messages with Debug.WriteLine if the debugger is attached to make it very easy to trace issues in debug mode.
In Silverlight you may want to consider the Logging and Exception Handling Application Blocks from the Silverlight Integration Pack for Enterprise Library.
Using the BizTalk ESB Toolkit 2.0
We are working on a project where we need to call a proxy to a web service which is a DLL. We have no problems doing this via an orchestration since you can use a static port and configure it to use the SOAP adapter with the web service setting pointing at the assembly in the BizTalk Admin interface. In the itinerary though there doesn't seem to be an obvious way to do this since dynamic ports don't have the option to use the SOAP adapter.
There is a good reason why we want to do this, don't worry.
Following on from this, we implemented a custom adaptor provider but are having problems getting it to work.
We followed an (old) example shown here:
The custom adaptor provider inherits from BaseAdapterProvider and overrides the SetEndPoint(Dictionary, IBaseMessageContext) method.
The method extracts the assembly name, type name, and method name that are passed in via the resolver dictionary and then writes them to the pipeline context:
pipelineContext.Write("TypeName",
"http://schemas.microsoft.com/BizTalk/2003/soap-properties", typeName);
pipelineContext.Write("MethodName",
"http://schemas.microsoft.com/BizTalk/2003/soap-properties", action);
pipelineContext.Write("AssemblyName",
"http://schemas.microsoft.com/BizTalk/2003/soap-properties", assembly);
and sets the transport type to soap:
pipelineContext.Write("TransportType",
"http://schemas.microsoft.biztalk.practices.esb.com/itinerary", "SOAP");
In all other respects the adapter provider is nearly identical to the example shown in the link above, except for the obvious change from SMTP to SOAP.
The adapter provider assembly is signed, GACed, and added to the esb.config.
The adapter provider is called from an itinerary that only calls the service and then returns the response. We are testing the itinerary from the Itinerary Test Client that is shipped with the toolkit. Event logging within the custom adapter shows that the adapter code is being called. The problem is that the message is not being routed to the service proxy. The event viewer gives the following error:
The Messaging engine failed to process
a message submitted by adapter:SOAP
Source
URL:/ESB.ItineraryServices.Response/ProcessItinerary.asmx.
Details:The published message could
not be routed because no subscribers
were found. This error occurs if the
subscribing orchestration or send port
has not been enlisted, or if some of
the message properties necessary for
subscription evaluation have not been
promoted. Please use the Biztalk
Administration console to troubleshoot
this failure.
Investigating the suspended service instamces in Group Overview shows two things:
The values for assembly name, type name, and method name are being set correctly.
The message body is missing.
We have tried configuring the send and receive pipelines on the send port to be both XMLTransmit/XMLReceive and ItinerarySendPassthrough/PassthroughReceive and it makes no difference.
Is there something obvious we might have missed? Do you have to explicitly pass the message body through? If so how?
EDIT:
Following a request from the BizTalk ESB Toolkit forum I am posting screen shots of the itinerary, context and send port filters.
Itinerary,
Context,
Port filters.
Many thanks, Nigel.
first of all I'll say you are trying to over engineer the solution. Adapter development is not trivial and there are various things you need to take in to consideration. Developing and Deploying adapters are categorized as platform changes, which effects your whole environment, so if you are not familiar then your shouldn't do it. I would recommend you taking some other route. At this point I personally don't have enough insight into ESB internals, so won't be able to comment on it. At worst case you may be better off using the .NET proxy dll directly inside your orchestration (expression or message shape) rather than building an adapter. Even though its not recommended approach, still I feel its better than custom adapter approach.
Semantically, I don't see why a solution that involves a WCF-BasicHtpp adapter would not work in your scenario. In any case, I would definitely try to see what happens with a WCF-BasicHttp adapter, and once I got a working solution, I would switch to a custom SOAP adapter if that is really necessary.
Currently, your solution is weird - in the sense that you have an On-Ramp directly connected to an Off-Ramp. I've never seen that in any of my itineraries. You might need to create an intermediate messaging or orchestration Itinerary service in betweeen.
Otherwise, the message effectively gets published to the message box and obviously there is no subscribers for it, hence the error you encounter.