Is there anyway to prevent an SB-Messaging Receive Location to not be disabled if the connection to an Azure Service Bus Queue is lost?
I would like to set an 'retry to connect' property after X minutes.
Is this possible or do I've to scan the eventlog to see if the Receive Location gets disabled and then go to BizTalk administration and enable the location manually?
The solution I found were adding a script that controls if the receive location is active, if it's not I start the receive location.
Added the script to the Task Scheduler.
Related
I have set up a BizTalk environment and am trying to follow a tutorial on github: wmmihaa / BizTalk-Server---Developing-Integration-Solutions.
Unfortunately when I have configured the server as the steps say and then when I copy the path that the tutorial says I should copy into send ports it does not show up in file explorer. Then I create the path myself and browse for it (same name as in tutorial) and I proceed to start the created application the text file does not show up in the folder and cannot be copied to the receive location as the tutorial says I should.
I have tried restarting the computer and application and tried to change the path (don't know if I can). Does anyone know why the file might not be showing up?
Yes, you have to create the folder manually, just setting the path in the send port won't create it.
There can be various issues
The file is not even picked up. This can be due to
a. The Reive location not enabled. Fix: Enable the receive location.
b. The file mask on the receive location doesn't match the file. Fix: Either change the filename or the filemask.
c. The BizTalk Host Instance user doesn't have the correct permission on the folder to pick the file up. Fix: Give the BizTalk user Full permissions of the folder
d. The host instance that the receive location is running under is Stopped. Fix: Star the host instance.
The file is picked up but the message suspended. This is caused by the filter/subscription on the send port not matching the Promoted Properties on in the message context. Fix: Fix the send port Filter.
The message is in an active state but not sending. Cause: The host instance that the send port is under is not started. Fix: Start the Host Instance the Send Port runs under.
we operate CENM(1.2 and use helm template to run on k8s cluster) to construct our own private network and keep on running CENM network map server for a few week, then launching new node start failing.
with further investigation, its appeared that request timeout for http://nmap:10000/network-map causes problem.
in nmap server’s log, we found following output when access to above url with curl.
[NMServer] - Error while handling socket client message com.r3.enm.servicesapi.networkmap.handlers.LatestUnsignedNetworkParametersRetrievalMessage#760c53ea: HikariPool-1 - Connection is not available, request timed out after 30000ms.
netstat shows there is at least 3 establish connection to the database from the container which network map server runs, also I can connect database directly with using CLI.
so I don’t think it is neither database saturated nor network configuration problem.
anyone have an idea why this happens? I think restart probably solve the problem, but want to know the root cause...
regards,
Please test the following options.
Since it is the HikariCP (connection pool) component that is throwing the error it would be worth seeing if increasing the pool size in the network map configuration may help - see below)
Corda uses Hikari Pool for creating the connection pool. To configure the connection pool any custom properties can be set in the dataSourceProperties section.
dataSourceProperties = {
dataSourceClassName = "org.postgresql.ds.PGSimpleDataSource"
...
maximumPoolSize = 10
connectionTimeout = 50000
}
Has a healthcheck been conducted to verify there are sufficient resources on that postgres database i.e basic diagnostic checks ?
Another option to get more information logged from the network map service is to run with TRACE logging also:
From https://docs.corda.net/docs/cenm/1.2/troubleshooting-common-issues.html
Enabling debug/trace logging
Each service can be configured to run with a deeper log level via command line flags passed at startup:
java -DdefaultLogLevel=TRACE -DconsoleLogLevel=TRACE -jar <enm-service-jar>.jar --config-fi
Our BizTalk 2016 environment consists of 2 application server running in a group with CU5 and FP3.
We have 24 applications deployed. Across this applications we have 27 receive locations with the new sFTP WinSCP adapter configured. For all sFTP receive applications we have the "Connection Limit" configured to 5. We have 6 different sFTP Server we are connecting to.
After approximate 2 hours, we have the following event log warnings and the receive locations stop working:
"The adapter "SFTP" raised an error message. Details "The WCF service
host at address "sftp://..." has faulted and as a result no more
messages can be received on the corresponding receive location. To fix
the issue, BizTalk Server will automatically attempt to restart the
service host."
Against the event log message the service host is not restarting automatically.
Has someone any idea how to fix this issue?
Try out CU7 as it includes a couple of SFTP fixes.
The latest version of BizTalk Health Monitor comes up with the following Important Warning
The host instances of 'hostinstancename' need more worker threads per cpu to run correctly SFTP Receive Locations. Increase so the "Maximum Worker Threads" property to 500 for these host instances and be sure they are dedicated for this SFTP Receive Locations
So things to look at are
Have a dedicated host for receive locations using SFTP
Increase the Maximum Worker threads setting to 500
Check how frequently you poll (the default is 5 seconds)
Put a schedule on to only poll during the periods you need.
Disable message body tracking if it is not needed.
So I have been running into this issue since we set up our BizTalk Server on a new network. We have the same MSMQ settings between the two servers.
The data stays in our AX MSMQ folders and has the correct permissions.
The system does not ever throw an error until I stop/restart the Receive Host Instances.
(we get one of these errors per message in any of our MSMQ ports)
Full error:
A message received by adapter "MSMQ" on receive location
"recv_loc_file_ax_2012_customer_message" with URI
"FORMATNAME:DIRECT=OS:AXSERVER\AXOUTPPDCUSTOMER" is suspended. Error
details: The Messaging Engine is shutting down. MessageId:
{65E24FE1-317E-4636-AFC7-B43FACBDBEDF} InstanceID:
{6618EEB3-9B72-4123-BD8C-422661A59BDD}
Then the messages finally appear under suspended instances after this error occurs. I am able to resume them and they all process as expected.
I have looked almost every, Anyone have suggestions for what is causing these messages to not be read into my MSMQ receive ports properly?
EDIT: This BizTalk server is connecting to a remote AX server's MSMQ, but I am doubting this changes anything I have not already looked into.
Thank you very much.
The error was on the guys who installed MSMQ on the remote server; the active directory was not set up thus not properly autenticating my BizTalk Server account.
Answer for BizTalk: The way to find these hidden errors was by changing the MSMQ BizTalk receive port to a WFC-NetMSMQ.
Other: we are a little baffled that BizTalk was able to take the messages out of MSMQ despite the AD not being set up and "force messages through" but this is a minor detail to note.
BizTalk reference
I'm troubleshooting a very generic BizTalk error that is resulting in transmission/routing failures (see below). Even though my receive location is started, it does not appear to be listening for anything. When I run a query for all Activation Subscriptions, the receive port is not showing up in the list. I cannot figure out why it is not subscribing to my send ports.
Error:
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.
One Way Receive locations don't have Active subscriptions, only Orchestrations, Send Port Groups and Send Ports do. For a One Way your Send Port should be listening to your Receive Port rather than your Receive Port to your Send Port.
If it is a Request / Response port then see section below
One Way Receive Location
A Receive Location picks up from an external location and it goes via the associated receive port and publishes into the message box.
As your error clearly indicates that the message has been published to the message box the receive port is obviously working (although maybe not correctly) or it has been published back from a send port or orchestration.
What you have to check is
The context properties on the suspended message using BizTalk Administrator
The Subscription belonging to the Send Port / Orchestration that you expect to handle the message
Compare the two and see what does not match
The possibilities are
Your Receive Port is not promoting the properties you expect. Check the receive pipeline and promoted properties on the schema. If your pipeline is set to pass thru, only some of the standard promoted properties will be there and no message type or promoted properties from the schema, if you need those promoted properties set your pipeline to XMLReceive or a custom pipeline with either a XML Disassembler or a Flat File one.
Your Send Port / Orchestration are not in an Enlisted state, if they aren't enlisted then no subscriptions are published for them. Enlist or Start them.
Your Send port/Orchestration subscription is wrong (does not match the message context properties), correct them so that they match.
Request/Response Receive Port
For a Request Response Receive location/port it creates an Instance Subscription for a message which looks for BTS.EpmRRCorrelationToken (which contains details of the hostinstance, port and a GUID) and BTS.RouteDirectToTP == True
It works out of the box if you either have a Request/Response Send port subscribing to a Request/Response receive port, or if you use a Request/Response Port in an Orchestration. If you use separate Receive Send Ports in the Orchestration you need to set the above properties in your message construct shape manually.
See Messaging-only request-response correlation
Thanks for the clarification on receive locations. I'm new to BizTalk, as I have recently inherited the role of supporting it. The problem ended up being an incorrect reference in an endpoint behavior extension in the receive location.