I has a problem with send port and an application: The process cannot access the file because another process has locked a portion of the file.
I guess the problem is while BizTalk send port is writing a file, the application pickup this file and process.
My scenario:
I have an orchestration with a file send port to write a file to a location.
After this port I have another send port to call an application to picking the written file and process.
I think: While file send port is writing and not yet finished, the orchestration does not wait but continue next step - calling application. And this leads to above error.
Is my assumption correct?
And how can I solve this problem?
You are absolutely correct your orchestration basically throws the message in your send port and continues, but you can change this behavior and I'll give you a really simple solution here it is
* Set your Logical send port like this
Now your orchestration will wait for delivery ACK
*To make things cleaner
Create a scope and catch the Microsoft.XLANGs.BaseTypes.DeliveryFailureException which occurs when you don't get an ACK
*Also add in your catch block a suspend Orchestration shape so you can resume your orchestration if your message doesn't get to its destination :)
This works with both File and FTP protocol, (I didn't test others)
Related
An instance of a BizTalk send pipeline has started to run continuously. On 09/12/2021 an attempt was made to send a file via SFTP, which retried several times but ultimately failed due to a network issue. The error from the event logs is:
The adapter failed to transmit message going to send port "Deliver Outgoing - SFTP" with URL "sftp://xxx.xxxxxx.co.nz:22/To_****/%SourceFileName%". It will be retransmitted after the retry interval specified for this Send Port. Details:"WinSCP.SessionRemoteException: Network error: Software caused connection abort.
For some reason BizTalk made another send attempt at 1:49pm on 10/12/2021 which succeeded as confirmed by the administrator of the SFTP site. Despite this, BizTalk continued making intermittent send attempts and the pipeline instance is still running. The same file has been sent 4 times to the SFTP server.
The pipeline instance in theory should have suspended at 9:47pm on 09/12/2021. I have been able to confirm definitively whether anybody resumed it, but it seems unlikely at this stage. In any case, after sending successfully the pipeline instance should have terminated and should not be re-executing intermittently.
Does anybody know what could account for this behaviour? This is occurring on BTS2020 with CU2 applied.
I've sent messages over SFTP where the WinSCP interpretation of the date-modified attribute doesn't work with a specific type of SFTP server.
With the WinSCP GUI a dialogue box appears and you can disregard this error, but this option isn't available with BizTalk's GUI. This error appears when a file with the same filename already exists on the server and is supposed to be overwritten.
My solution was to create a pipeline component that removed %SourceFileName% on the server. The pipeline component (just like WinSCP GUI) can disregard the modified-date.
We have an upcoming deploy for a system that processes a lot of messages through BizTalk. Since those messages are cumulative updates they need to be queued up during the deployment outage then processed in order when the deploy is finished. Since there may be a large number of them it’s difficult to do this manually.
One possible solution is to leave the send port stopped and let the messages suspend. We can then resume them in order when the deployment is completed.
Is it possible to run a SQL script (or a tool) against the BizTalk messagebox database that will resume suspended messages, for a specific port, in order of receipt?
If you have an ordered requirement (you either do or don't), then the Send Port should be marked for Ordered Delivery.
If so, then when you Start a Stopped Send Port, the messages will be processed in the same order they were submitted.
If you stop the port (but leave it subscribed) and start it again afterwards it should resume the message itself, or if not it is simple enough to go into the Administration Console and batch resume them.
However if the response messages of the send port are subscribed too by running Orchestrations you will not be able to un-deploy the Orchestrations until they have all completed, so stopping the send port would not work in this scenario.
Sometimes one option is if the initiating port is a one way receive, is to stop the receive location and let everything complete. You can then stop the application and redeploy and restart it and the send port will pick up all the waiting message to process.
If the above is not possible you may want to look at doing a side by side deployment where you increment the version numbers of all the assemblies in the solution so you can have both versions deployed at the same time and you can then allow the old version to finish running but have the new version processing any new messages.
The better option is to send messages to msmq, usually there is no extra coding required for this. You can just route messages to msmq using MSMQ adapter and then after deployment receive them in order as MSMQ adapter allows to receive in order. Just make sure you do a small test in yr QA environment before doing it in production.
What I am trying to do is ensure that my message is sent to it's destination prior to the rest of the orchestration executing.
My message is large (> 200M), in the orchestration I have the send shape to write the message to a physical location followed by a step to kick off another application to consume the file.
My problem is that this step runs prior to the file send port finishing its writing, and then the application fails to get the file.
I has followed Kent Weare's post: BizTalk Delivery Notification (Thanks Kent Weare), but was unsuccessful.
Could anyone give me some suggestions?
I have to develop an orchestration which uses a start orchestration shape followed by send port.
Scenario: If a "Sendport4" failed to send the message, I don't have to execute "Starting Orchestration Shape".
But in my case, when "sendport4" is getting failed, It is calling "Start Orchestraton Shape".
To handle this schenario, I tried to put the exception handling, But didn't worked.
Can any one please help, what can do handle this?
Set Delivery Notification to Transmitted on the Send Port shape in the Orchestration.
I am trying to open the COM1 port but I am getting this error message "Access to the port 'COM1' is denied". I am writing a program for sending SMS via .NET. I expect there could be an error, but the error "Access denied" should not be arisen. Please give me any solution. If port requires any access privileges then how can I do that?
First, make sure the serial port exists. Check the Device Manager; right-click on My Computer, select "Manage" from the context menu, select "Device Manager", expand "Ports Com & LPT". If Com1 is not listed, you will need to enable it in the BIOS.
If COM1 is there, then another program has left it open. Access to COM1 is exclusive; only one program can have it open at a time. Fax software or a modem could have it open, or you could have left it open yourself.
This is easy to do. If you work on a program that opens the port and forget to close it, or if an error occurs and the program terminates without closing the port, this is the message you will get the next time you try to open COM1. Only the program that opened the port can close it. "Catch" or "Finally" blocks are good places to close the port and prevent this.
There's probably something else using COM1 (auto sync programs tend to be quite bad at grabbing COM ports as soon as they become available).
Try downloading PortMon and it will tell you exactly what's using the port.
Since you tagged this asp.net, are you trying to access the port with multiple threads? (as in on a request, accessing the port, creating the connection, sending data, closing connection, closing the port?
If you are, this is also a problem. If I am not mistaken, only one thread can access a com port at a time. You will need to write some code to ensure that only one thread is trying to access the port at a given time. Typically I would suggest a queue and a worker for that queue that does the job.
There is probably another program using the serial port. Have you tried firing up hyperterminal?
If you are trying to use ASP.Net under IIS there account running the website may not have permissiongs to the device, as well as, there could also be conflicting thread/multi-access issues. Something to consider would me to write a service that manages requests for the COM port and then talk to that service from ASP.Net. This will allow for split permissions and controlled single access to the COM port. Any other hack has the potential of causing lots of problems.