I have a BizTalk system where I have a need to create Zero Byte file output. Basically, I need to send out a report every day to our various partners. If there is no data to send for the day, I still need to send a file, but there should be nothing in the file.
It seem that if there is no data to send, BizTalk just drops the whole thing and decides to send nothing. I have read on how to read zero byte files in, but nothing on how to create them for sending out.
Does anyone have any recommendations or links?
Please see the link below. Some times you can have the answer.
http://biztalkwithshashikant.blogspot.com/2011/04/processing-empty-files-in-biztalk.html
This is how I have seen this handled:
Modify the sample File Adapter in the BizTalk SDK to allow 0 byte files.
Create a custom Pipeline Component that detects a 0 length message and writes the 0 byte file using the same filename pattern as the Adapter.
Related
I'm trying to copy data from a database and place it in S3 using nifi. I'm able to copy the data from database and place it in S3. Now I'm trying to add error handling for this flow. I just added the PutEmail processor for error notification. I just gave a wrong bucket name to validate the Email. This PutEmail processor is getting triggered for each and every flow file(As there are 100 flow files mail is triggering 100 times). I just want to trigger this PutEmail(notification) only once whenever there is a error in the flow. Any suggestions on this please.
Below is the Flow:
Any suggestions on better(Generic) error handling will be helpful for me.
For your use case, MergeContent would allow you to batch several FlowFiles over a given duration to be rolled up into a singular email.
You could additionally do some additional transforms to only get the key parts of the content and/or attributes to provide source FlowFiles to MergeContent that would give a summary listing in the message sent.
You can implement custom ReportingTasks which will periodically sends reports based on Need
On a WCF rest service I am dealing with streams. In a service method I am uploading a stream in a data contract which works fine. And on service side I process the stream and its position is now at eof. After doing that I need to set its position to 0 again therefore I can save it there. But it throws the exception:
Specified method is not supported.
Does it mean I can't process a stream more then once? If it does I will need a workaround for that :/ and only solution pops into my mind is sending the stream two times so I can process it separately, but it is not good since I would have to upload it twice.
Any help would be appreciated.
Funny that I found my own solution :) first I saved the stream, then read it from that path for further processes over that stream. its interesting that finding the solution didn't require more detailed, technical information but a change of logical approach.
I have configured a WCF service to transfer data on a streamed transfer mode. I think I have set the configurations properly because I'm able to transfer files above 100Mb and that's more than I need.
Now I'm calling my transfer service three times to get three different files that don't pass the 2 Mb each. The problem is that as soon as I call for the third file, my program freezes and I don't get any response anymore, forcing me to close the program.
I don't think this is a file size issue because I have tested passing files of 20 Mb of size and only the first two get to the client just fine. But i don't have any response from the third call.
Is this a configuration issue which may limit the service calls to just two?
Best regards
HALF-SOLVED
Well, First of all I could not find out why the client cannot reach the server after two succesful requests, it hangs out spectacularly.
Now I know that I'm able to transfer 500 Mb on the service I'm sending data to the client as a zipped file. Then I call to 7z.exe (7zip) to unzip my files.
This is not a way to solve this issue. The problem still exists and I think there's a way to solve it the right way. I'll be posting the answer as soon as I find it, but in the mean time, my users will keep using my system.
I am uploading files from clients to server... when the server program receives the stream, property Length is not supported and CanSeek comes false, how would seeking be possible?? I can get the length if I read it in the client and send as a message header in the message contract but don't know how to seek. Ideas??
WCF is not technology for file transfers. Moreover seek is not supported by StreamFormatter used internally because the whole idea of seek in distributed application is nonsense. To make this work correctly internal stream will have to be network protocol with control flow over transferred data which is not. Internally the stream is only array of bytes. It means that even if WCF supported seeking you would still need to transfer all data before seek position.
If you need resume functionality you must implement it by yourselves by manually creating chunks of data and uploading them and appending them to file on the server. Server will control last correctly received chunk and refuse chunks already passed. MSDN has sample implementation using this as custom channel.
The stream sample here http://go.microsoft.com/fwlink/?LinkId=150780 does what your trying to do.
WCF\Basic\Contract\Service\Stream\CS\Stream.sln
the sample is explained here
http://msdn.microsoft.com/en-us/library/ms751463.aspx
If a user requests a large file from an Apache web server, but cancels the download before it completes, is this logged by Apache?
Can I tell from the log file which responses were not sent fully, and how many bytes were sent?
Yes, it logs those requests, but you need to use mod_logio to know the actual bytes sent, else it will show the total amount of bytes of the file. And to know which have failed you'd have to either:
use the %X format modifier and use a custom log format
compare the actual bytes sent against the files' sizes (why would you if you have the first option :-) )
Yes. If I remember correctly, it will show the amount of bytes transferred before the download was interrupted. You could then work out how many bytes should have been sent for that request and compare.
If you're using PHP (as the question was tagged a minute ago), you could probably do some sort of response buffer, where you chunk out the file in smaller bits. Start off by working out how many chunks you need to send, write a log (to db, or the syslog) to say you've started and once you hit the final chunk, another to say you've finished (or delete the first).