Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
oipi Set_Printer
Should I be able to call a subroutine that uses oipi set_printer to create a report to a pdf file.
Debug shows it executing the code but pdf file is not produced.
Testing via Postman.
OK when run from the application. using same routine.
Debug shows it executing the code but pdf file is not produced.
Testing via Postman.
OK when run from the application. using same routine.
Comments
If you don't need the PDF document to be returned immediately, you can always return a response that tells the visitor that the report will appear in an email shortly (or a link to pull up the report). This is how PayPal does it.
OIPI report is too complicated for me to learn BRW and rewrite in the short time I have.
1. How do I ensure that OI gets loaded on the web server as minimised as possible.
2. What is the best method to do the 'create a mechanism where the web service oengine does a pass off to the desktop OI (and then it waits for the desktop OI to create the PDF document)'?
3. so the Desktop OI would be creating to the local path, but the api service would be returning the web virtual path for the Web app to retrieve and display?
1. I think Bob Carten has suggested using code to launch OI on-the-fly using the RTI_TASKMANAGER. This will eliminate the need to load OI automatically. You can also launch OpenInsight as a Windows Service. This article might be helpful. There are third-party utilities that you can install and then configure to run one or more applications as a service.
2. There isn't a "best method" since each application has different requirements. We use our own technology to send direct requests to the running OI. Others create a request in the form of a record written to a shared table or a text file in an OS folder that the OI application monitors. The information in the request can specify the name of the PDF file and this is what OI uses. Then web service engine can loop until the file is generated in the designated folder.
3. Normally the web service would read the PDF file and return the data as binary. You would not need to worry about virtual paths.
But of course in a web environment things need to happen fast.
Would it be faster to load openinsight as a service and sent RTI_TASKMANAGER requests to it, as opposed to RTI_TASK_SUBMIT loading openinsight each time.
If Openinsight is running as a service, would you still only have to do RTI_TASK_SUBMIT with, I assume '0 Add task to the queue'
We decided to use our SRP DirectConnect control on an OI form that gets immediately notified by the web API engine via a special method. This triggers an event in OI to run the report.
Thank you.
Just running RTI_TASK_SUBMIT as is would be must simpler (Less to remember in the golive server setup).
Yes, that's right, still not live, the web developer is 12 months behind.
How would I do that using the HTTP_ functions at my disposal.
Do I assume base64 encoding, then, how do I return it in the body, is there a header setting or the web developer just needs to know it is a field that need unencode it.
Definitely would not have worked that out.
With the SetResponseBody:
If I leave out the ContentType the content type shows as Content-Type →text/html
and the body contains what would appear to be only binary data(which is good)
If I put ContentType as application/pdf (or application\pdf) the Postman testing is wanting me to save it and then shows PDF saved in the body only.
If I tell the Web guy that the content is a pdf decoded base64 binary, the value in the content-type shouldn't matter should it. He is not a parameter driven person he is hardcode and would not be looking at the content-type, just processing as he expects it to be returned
HTTP_Services("SetResponseHeaderField", 'pathtopdfdoc',PathToPdfDoc)
ContentType = HTTP_Services('GetResponseHeaderField', 'Content-Type') If Len(ContentType) else Begin Case Case Body[1, 1] EQ '{' ContentType = 'application/hal+json' Case Body[1, 4] EQ '%PDF' ContentType = 'application/pdf' Case Otherwise$ ContentType = 'text/html' End Case HTTP_Services('SetResponseHeaderField', 'Content-Type', ContentType) endI would expect Postman to try and download the file because it doesn't have a PDF viewer built-in. If you did the same thing with an image file, Postman would display it.
<1u�](n?歊��jׅQtӎ4�p4�}�
As to what you should do, that depends on you and how this is supposed to work. If you intend to display the PDF directly in the browser after the request is made, then do not encode it. If this needs to be used by something else that knows how to decode, then leave it as is. However, in that case, the Content-Type is properly "text/html".
http://localhost/PARSONS_Documents/16333 PHONE QUOTE PQ ORTHODOX BURIAL-2.PDF
looking like this:
"pathtopdfdoc": "http://localhost/PARSONS_Documents/16333 PHONE QUOTE PQ ORTHODOX BURIAL-2.PDF"
I use task_manager to call and run an OI task that creates the PDF and it returns the filename and I assemble the virtual path.
It may not be ReSTful, but that has gone out the window with this Web developer.
A similar thing is already done for me when I calling HTTP_Resource_Services
where I have a symbolic "photo_file_paths" that produces this, which works for the Web developer.
.
.
.
"photo_file_paths": [
"http://localhost/StockPhotos/1010 Tweed.png"
],
.
.
At any rate, your URL should not attempt to identify a file name (e.g., "filename.pdf"). The URL should have a very simple structure that is meaningful to the business context. This is referred to as a "Semantic URL". That URL then identifies the abstract resource on the service. The format of that resource (e.g., PDF, HTML, JSON, etc.) is arbitrary and identified through the headers, like Accept and Content-Type.
Without being overly familiar with the way this PDF resource is being utilized, I might have suggested this URL:
GET http://localhost/PARSONS/Quotes/16333
You would then have a Quotes API that checks for the format being requested and then returns the content in the format you allow for. Thus, if you wanted to return the same information but in a different format, you have that option and you don't have to change the URL at all.
I do understand what you are saying, just return the pdf record in body with application/pdf.
thank you
Deployed to test server, which is a terminal server that has the oi application.
The call to rti_task_submit , testing via Postman, just sits there, task manager show oengine as 40% and Openinsight as 0%. Although not seing engine on the task bar as I was on the PC.
I know rti_task_submit is getting run, because it initially returned error re systasks not being attached.
I will have to try and see if Bob will respond to my posts. And to think I was so excited it was all working.
Going back to your original question about using a "PathToDPFDoc" setting, hopefully you realize this is unnecessary because the URL *is* your path.