I don't. Since Component is server-side, what you get is a full path to the file (in a binder variable). I have never used the GET_FORM_FILE, nor I can't find it documented, so I don't know what should be returned. Besides, even for GET_FILE it was a bit of try&see, but since you have the full story described with the result in the last thread, you should be able to replicate it for your needs.
Jiri.Machotka-Oracle Problem is when i am trying to get using RIDC api. I am able to get the output as Service Response or in stream.
But when i am using intradoc client - i am getting result as dataBinder. That is the issue.
Either , i can get responseStream from DataBinder or i cn use ServiceResponse object in Intradoc.
I have seen the other thread: getting file using service GET_ASSOCIATED_DISCUSSION_FILE and honestly, I'm missing the most important piece of information: what are you trying to achieve? And here I don't mean 'download an hcsp in a web-viewable format', but rather 'I've got a form represented as an hcsp, and here are my use cases...' My guess is that most likely majority of them can be supported OOTB, just if you configure the system properly.
Please, start from this angle.
To your last questions: RIDC is a client-side technology (even though in theory you can could create a RIDC client program running on a server, but why?), whilst Intradoc is server-side. RIDC API is publicly available - see References and APIs for Oracle Fusion Middleware 11g (126.96.36.199), not sure about Intradoc, but I don't think it contains anything similar to the ServiceResponse class. In the thread I mentioned earlier there is a way how to get the path to the file returned by GET_FILE, and since you are at the server, you can easily create a stream using pure Java (returned to whom?). As I wrote in the beginning of this answer, however, I am missing the reason why this effort is necessary - using Intradoc classes presumes that the code is within a component, most likely in a custom service, and there is no information what the purpose of this service should be.
Understood. One last question: when? (and why?)
I understand that PDF/A might be required due to long-term preservation requirements, so most likely, this action might be required as a part of your retention schedule. Also, if you want to convert a discussion file (most likely attached to a real item), what should happen to the base item? Sometimes, it is required that the base item and auxiliary files (such discussion, protocols about anti-virus check, digital signatures checks, etc.) are "packed" together inside so-called "archiving packages". Is this something close to your requirements?
One thing I would look into is the conversion mechanism. Recently, a slightly different question was raised from this area (Change dFormat, dConversion metadata using RIDC) and one possible solution would be enhancing conversions via createWebViewable filter event.
I see. Just by chance, shouldn't the archiving package be created according to ETSI standards (such as XAdES)?
If so, you could convert your file to XML, rather than PDF/A, which is another allowed format for long-term preservation, and which is quite easy to achieve. Note also that you will need that during the package creation - and there will be more to do anyway, so using IBR for this kind of task might not be optimal.
I am not understanding why you are talking about the requirements of the conversion process when really the question stems simply from:
How does one retrieve a the 'response as a stream' using the available server side components that is similar to the method used by RIDC?
This would ring true for all services that return a stream such as GET_FILE and GET_FORM_FILE.
If you read last two answers by the author of this thread, you will see that the purpose actually leads to creation of archival packages - in a nutshell, when done, you take everything (incl. threaded discussions), pack it together and stamp it with an electronic signature and timestamp. There are not all necessary details mentioned yet, but I am almost certain, that no streams will be needed; possibly, not even IBR. Either way, if you are looking just for this answer, refer to my first post in this thread and the thread referenced there.
The solution that you had previously posted in the Unable to download Document using the GET_FILE service won't quite work.
In the GET_FILE solution you are still getting the PrimaryFilePath or FilePath (doesn't matter in this case) which will return the HSCP file. This isn't what Vinay wants. Vinay wants the HTML version that is rendered by calling the GET_FORM_FILE IdcService.
Calling GET_FORM_FILE works great through RIDC returning the HTML from the stream. This doesn't work while on the server side in a ServiceHandler class.
Do you know of a way to get the stream similar to RIDC?
Thank you very much for your insight.
Are you, guys, somehow linked together?
Concerning, GET_FORM_FILE, I don't know this service, nor I can find it document (I'm starting to repeat myself), so without a bit of exercise which might I take a couple of hours (or even days), I am of no help with your homework.
Doing one step back, your problem actually is how to get a stream with a server-side component, because the necessary class, ServiceResponse, available in RIDC is not present in the server-side intradoc libraries. Again, I don't know. Unlike RIDC, this API is not publicly documented (even though I think I have seen links to API somewhere in the forum). I can imagine, however, you won't find anything like that there - keep in mind that RIDC is a client-side technology, so the needs for data interchange might be different than to those apps running on a server.
Doing yet one step back, I asked, why you need it. The answer was that the aim is to create a PDF/A version of ThreadedDiscussion within an archival package (AIP) and you need the stream to pass it to IBR. Since I know a little about AIPs and long-term preservation, though, of course, not exactly in your context, I have a suggestion which might lead to a simple solution: don't use PDF/A, but XML, which is another format allowed for long-term preservation. If you can afford that, you can easily "convert" HSCP, which is "XML-formatted IdocScript", to XML (it is as simple as changing the file extension of the native file). Note that you will need a piece of code that will create AIP for you anyway.
If you yet want, or must go the hard path, one advise that I may share is to use Java reflection API to "document" the intradoc classes for you. Long time ago I created a program, which reads the jar and searches for classes according to criteria I have chosen in the program (e.g. implements an interface). I no longer have it, but it takes a day or two to create.
Yes, in fact we are colleagues.
We were working on similar problems regarding streams similar to RIDC requests so I have taken over the issue on our side.
If you don't know anything about this issue then that is fine. We can keep looking.
Retrieving the file from the system isn't plausible for Vinay because it needs to go through the HTML formatting that the ThreadedDiscussion component provides via the GET_FILE_FORM service (which works through RIDC).
We've decompiled this Java and didn't find anything useful. I'm attempting to retrieve files on the server via GET_FILE and in some use cases not able to go to the file system because the renditions are stored in the database.
I agree with you that unfortunately there is little to no documentation around these classes/components. Not only that they are riddled with inconsistencies.
Also, redefining our requirements isn't an option.
We've already decompiled the code and integrated it with the IDE to search. I'm not really understanding what you mean by a reflection based documentation program to search for classes based on criteria.. but it sounds cool.
Of course it would be easy convert the HSCP format to another 'more usable' format and we may have to hack it to create the necessary HTML. Thank you for your help but please stop suggesting a business requirements change. Our rather large customer wouldn't hear that.