Whilst this isn't directly a programming question, the answer will highly influence the solution adopted.
I am looking at developing a Java client to transfer data (files) into Informatica Powercentre Web Services Hub (WSH). Best practice suggests to use MTOM for large files being sent via SOAP requests.
I'm assuming support for consuming MTOM attachments is vendor specific, one can't assume it works out of the box ?
If anyone can confirm whether Power Center 9.x supports this, it'd be muchly appreciated. I've spent a lot of time on the Informatica Communities and reading documents but it is rather opaque to say the least.
RTFM
It appears that MTOM is not supported. From PowerCenter WebServices Provider Guide v 9.0.1 page 80 "WSDL Attachments".
The attachment must be a text file such as an XML document. You cannot attach binary documents... To use a binary file as a source, convert the file into hexbinary or base64binary before you pass it to the web service source. A hexbinary or base64binary files is treated as a text file.
Related
We have run a standard Jackrabbit WebDAV server and uploaded some files in it.
When we upload a new file with the same name we need to check if the file on the server is up to date and shouldn't be replaced. The initial idea was to use ETags but we it turned out to be too weak and is not suitable for the application.
So now the idea is to check the checksum (hash) of the incoming and existing files. As files can be pretty big and downloading everytime can be a time-consuming operation, it's better to have an option to easily obtain checksum for already uploaded files.
So my question: are there any options to get a checksum for files uploaded to the server? Maybe there are some other options or features that will help in such file handling?
There used to be Content-MD5 for that (in the HTTP spec, not Jackrabbit).
The HTTP Working Group currently works on new digest types (see https://httpwg.org/http-extensions/draft-ietf-httpbis-digest-headers.html), but this is still work-in-progress and is not implemented in Jackrabbit.
That said, getting a hash definitively could be implemented as a WebDAV property, or using a WebDAV extension report.
You can use md5 or shaxxx hashes for this purpose. I found a prebuilt MD5 Javascript library on github. I'd be shocked if there wasn't one for Java
I use Java SOAP web-service based on Axis2 1.4.1 to exchange data and attachments since years; no matter so far even if big attachments since the web-service implements MTOM.
This till last week, when a webservice WS client started sending huge attachments (around 1GB) as base64 inline text within the SOAP body (no MTOM no SwA).
I was confident that Axis2 attachment caching feature would solve also in this case, but this is not true and OutOfMemory occurs.
After some attempts my understanding is that attachments are cached to disk (and not kept in memory) only if the WS client sends them as MIME parts.If sent as base64 text within the SOAP body they are kept in memory.
I also tried to replace Axis2 with CXF (I'm prepared to change my WS framework if it is the only solution) but I experimented exactly the same behavior.
I'm wondering if I'm missing something or someone having my same issue found a solution.
I cant't believe that my webservice can manage big attachments only if the client implements MTOM.
Thanks in advance for any possible suggestion.
Situation:
The System is fetching Emails via standard methods (Pop3) from a Mailserver and sends them to the Archiving component as multi-part messages (*.eml files).
If the mail was sent from Outlook it may contain an OLE-Object for example a MS Word, MS Excel and so on. There are several ways to include such an Object, for example via Menu "Insert->Object"
Problem:
Our requirement is now to extract those OLE-Objects archive them as separate attachments. It would be best to do it in Java or other JVM Languages. Other Languages and Frameworks would be possible but they must be working on different platforms (Win, Linux, Unix)
The problem is we haven't found any library or functions in the libraries to do this.
First issue is, that the message the receiver gets depends on how outlook is configured:
It may send RTF messages: Then the receiver get's a message having an attachment "Untitled Attachment.bin"
It may send HTML messages: Then the receiver get's a message inlcuding an attachment "oledata.mso".
What we've tried so far:
We tried Apache POI, especially POIFS to load the file "oledata.mso" but it complained about that some header value is wrong:
Invalid header signature; read 0xD7EC9C7800013000, expected 0xE11AB1A1E011CFD0 - Your file appears not to be a valid OLE2 document
We found a website talking about the same issue. As far as we understood, the oledata.mso is an collection of Compound File Binary Files. Which should also be parsable with POI individually because the OpenMCDF is doing the same things as POI.
On this website they somehow separate the parts and parse them separatly. But we haven't found a similar function or any specification how this is done.
Can anybody please shed some light on this?
I have a requirement where I intend to build a tool to scan the email contents including the attachments. The email servers is either going to be SendMail or z/OS Communication Server, both support SMTP. The sever is not Miscrosoft implementation so MAPI or Outlook API is not there into picture. The tool would be Java based code and basically need to look for contents that are not-permitted based on some rules. What are my options here? There is the possibility of using a proxy server but we are looking for a more direct approach.
The z/OS Communication Server SMTP implementation has a built-in "exit" capability - see http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B4B0/30.3?DT=20110609204120#HDRWQ1299.
The exit is called for just about any SMTP activity and it can examine, change or reject just about anything based on the rules you establish. It is generally written in IBM Assembler Language, but there's no reason you couldn't have a thin assembler layer that passes data to a Java app using whatever protocol you like (say, a pipe or a socket).
There are many little details to handle, such as character encoding (EBCDIC vs. ASCII or UTF-8, for example) plus weeding out attachments from email content. But using the exit preserves all the z/OS specific features of IBM's SMPT server without trying to recreate any of that yourself.
Good luck!
Is there a posability in Vaadin 7 or in Java generally, to check if a browser has an embedded pdfreader or not?
I need to know that because it depends on that how i open the pdf.
There is unfortunately no way to consistently check if the browser supports viewing PDF files or not. I would recommend using something like PDF.JS (https://github.com/mozilla/pdf.js) or FlexPaper (http://flexpaper.devaldi.com/products.jsp) on your web site to display your documents to make sure your visitors can see your documents
Both those options are available as open source
In a web application, Java (and per se, Vaadin) runs on server side, so you cannot know which technology is installed on client, in this case, the browser. Just fire your file download with the application/pdf mime header and let the client do it's work. If you want to fire it as a general file download, use application/octet-stream mime header instead.
Here's a more generic q/a on this topic: How to determine if the user's browser can view PDF files