Can anyone help me with this error message please?
Event Type: Error
Event Source: BizTalk Server 2006
Event Category: BizTalk Server 2006
Event ID: 5778
Date: 1/02/2013
Time: 7:15:04 AM
User: N/A
Computer: BIZTALKSERVER
Description:
The Messaging engine failed to process a message submitted by adapter:SQL Source URL:SQL://SQLSERVER/SQLDB/.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.
What the error is saying is that BizTalk can't determine subscribers for that message. So your starting point would be to check your subscription settings on Send port or orchestration receive shape filter expression.
Rather than checking individual ports, etc. - I'd look at subscriptions via the admin console as a starting point - when viewing the underlying subscriptions the answer as to why no matching subscription is found is sometimes quite obvious.
I get the same error message on a system that has been working fine for 36 months. I think it is related to orphaned messages after we restarted the host and send ports. I just went and resumed the message from the Biztalk Group page -> Suspended items/Resumable -> right click resume the message. all is well.
Check for the filters in your send ports i.e BTS.ReceivePortName= "Your Receive Port Name".
Check the relevant send port is started, Orchestration is enlsited with correct bindings and receive location is enabled
After 1st and 2nd steps, go to Plateform setting and restart your Host instances.
Refresh your application, Now go to Suspended messages in GroupHub and resume your serviceInstance which should be in resumable state. Now it should be working.
Thanks
Mayank
Related
My Office365 Adapter sometimes shutdown; the only thing I can find is these messages in the EventLog, which are rather vague:
11:26:28 am - The receive location
"Office365.PublishEmail.ReceiveLocation.IntegrationEmail" with URL
"O365Mail://email#mycompany.com/Inbox" is shutting down. Details:"The
error threshold was exceeded. ".
11:25:28 The adapter "Office365 Outlook Email" raised an error
message. Details "The Event Log Error Threshold was reached. The
adapter will continue polling, but further event log entries will be
suppressed. ".
11:25:28 The adapter "Office365 Outlook Email" raised an error
message. Details "An error occurred while sending the request."
11:22:43 Info Msg - from "BizTalkTMS": Service Heartbeat
So today, I enabled it, it got the emails that were queued up (so no security issues), and then it went through the same shutdown steps again. I noticed last time, the same thing happened, after getting about 7 or 8 emails after being enabled (I can see traces of our orchestrations that run upon receiving an email).
Today, I re-enabled the ReceiveLocation at 2:07 pm, and this time, no queue up emails were waiting. It disabled itself again with the same sequence of messages/errors starting at 2:17 pm. It disabled itself again at 3:00 pm.
Then I went to check the "Configure" button on that receive location, and now getting this message (first time I've seen it):
I have an idea on the above. We had the systems team apply registry changes to force all apps to use TLS 1.2. (See here: BizTalk 2016 Office 365 Adapter and TLS 1.2)
Above is in our QA environment. The "configure" button opens the next screen okay in our DEV environment. I'm restarted the same ReceiveLocation in DEV, and it is also get the warnings and presumable will shut down in a few minutes.
The "BizTalk TMS service" is running and writing heartbeat messages to the EventLog periodically.
When we first installed the BizTalk application with that receive location, it worked fine for at least several weeks.
If it just happened periodically, it might make sense if Office 365 has a short outage. But the fact that I restarted it, and it disabled itself again within an hour shows something else is probably wrong.
I'm probably going to create some type of alert/email for this, but would like any ideas if other people experience this and what exactly causes it.
Updated: 09/12/2022
In the System Event Log, when I enable the Receive Location, I see a multiple of these messages:
A fatal error occurred while creating a TLS client credential. The
internal error state is 10013.
They seem to stop when the Receive Location disables itself.
There are a few sites I'm reading about this, one of them is here: A fatal error occurred while creating a TLS client credential. The internal error state is 10013
Looking in the BizTalk Admin Console under tracked service instances and I can see that the default XML Receive pipeline starts, however it never completes. It remains at status "started" with the error code set to -1061153241. In tracked message events I can see the pipeline receives the message, however i can't see a "send" event type and it looks like the message is not sent to the MessageBox for the waiting orchestration to pick it up. My orchestration never gets initiated. There are no error messages in the event log, no suspended service instances, just the tracked service instance showing starting and not completed with the error code specified above.
I managed to resolve this issue. I had previously just GAC'd a dll and didn't update it as a resource in the Admin Console. Once I updated the Admin Console with this resource and restarted host instances the error went away. Thanks.
I am trying to poll data from SQL server and receive data in a receive message who have the schema from the table in SQL, then I use a loop to each row by row and transfer each row to file.
In administrator I found an error, the error is:
The Messaging engine failed to process a message submitted by adapter:WCF-SQL Source URL:mssql://win-f7kl176gt9v//user?InboundId=id2. 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.
Run a query to look at your active subscriptions and identify your receive port:
Then check against your messages promoted properties. The usual case is that your receive port has the wrong filter i.e. message type etc.
I've got a new production computer and installed my BizTalk app on there. The problem is that I don't see any messages in the event log, nor from my BizTalk app or BizTalk Server itself. The only message that appears in the event log is the following:
The following BizTalk host instance has initialized successfully.
BizTalk host name: BizTalkServerApplication
Windows service name: BTSSvc$BizTalkServerApplication
The source of that message is BizTalk Server. And no messages at all, even no logs about errors which I suppose already took place.
Just a quick thought incase you are still having problems.
I tried to write to the event log with a source type that didnt already exist and my BizTalk Host user account didn’t have permissions to create a new source type. This meant I never saw the entry in the event log.
E.g. (from example #Bill Osuch)
System.Diagnostics.EventLog.WriteEntry("MyBiztalkApp", "oh i did something");
Make sure either the MyBiztalkApp source exists or that your user has permissions on the event log to create it.
Also, if you have a lot of messages going through BizTalk you will probably want to implement your own logging so your event log doesn’t fill up. We used Log4Net for our implementation and a database to store messages.
If you're not getting any errors (suspended messages) as the messages process, you're not going to see anything in the app log. You could try adding an Expression shape to your orchestration and manually writing out some debug info:
System.Diagnostics.EventLog.WriteEntry("event type", "whatever...");
Does your application actually use the BiztalkServerApplication host? Check in the Biztalk Administration Console if all the host instances are indeed running. Is your application fully started? Messages are "put on hold" if your receive location is disabled for example.
To check this functionality, write to event log after every operation or shape in BizTalk orchestration.
Scenario-
Suppose you have to assigned a value to xpath of node in a map after transformation so in message assignment shape after you assign some value, you can write eventlog to admin console.
Ex. Suppose we have already initialized - "orderType" as "PO" in our expression shape and now we have to assign the value of "orderType" to the xpath of a node in our map then-
Shape- MessageAssignment(Under constructMessage Shape after transformation of map)
xpath(msgGetOrderReq, "/[local-name()='CustomerOrders' and namespace-uri()='http://example.com/EAI/IEmployee/v1.0']/[local-name()='ordertype' and namespace-uri()='http://example.com/EAI/IEmployee/v1.0']") = ordertype;
Next to this we want to print this information on the admin console so we need to write:-
System.Diagnostics.EventLog.WriteEntry("msgGetOrderReq", ordertype, msgGetOrderReq);
Build the project, Deploy and GAC it. Restart the host instance. Run the orchestration, process something and now you will be able to see the logs in admin console.
Regards
Mayank
Can anyone explain how I can remove service instances ?
- I've got a few which the BizTalk console shows as "Running"
- they are all in the Isolated Adapter
- tried doing a Stop with Full Stop option ...
- tried the Terminate Instance option ...
- even tried deleting the BizTalk application
But they're still there ??
my bad, the application delete did remove them, must have forgot to refresh
Event log has the errors ...
A request-response for the "HTTP" adapter at receive location "/foanite/BTSHTTPReceive.dll" has timed out before a response could be delivered.
but I still don't understand why the terminate wouldn't work
If you are running an Receive Location in an isolated host you normally need to perform a iisreset to be able to delete them.
If the IISReset does't help (it often doesn't) then use the BizTalk Health Monitor.
Select "Maintenance" from left-and tree view
For Task Type, select "Delete" and "Terminate Single Instance (Hard Termination)"
Paste the instance id taken from the BizTalk admin console
Click "Execute Task"