So many questions on the forum about the delivery manager and its integration into the concurrent manager in EBS, so over the next few postings Im going to try and clear the air and show you some of the options you have to get documents delivered from the concurrent manager, forms or OAFramework.
We need an introduction to the delivery manager before we start. Its a rich set of java APIs that can be used to send documents via:
- Email - pretty obvious, supports multiple document attachments, embedded HTML, multiple recipients, etc
- Fax - not up to communicating with a multifax board for high volume but definitely adequate
- Print - again obvious, uses the IPP for communication to the printer, has tray handling, copies, duplex, orientation, etc
- WebDAV - allows you to post documents to a repository such as Oracle Files Online, other 3rd party management solutions
- HTTP/HTTPS - posting docs to a web server
- FTP/SFTP - posting docs to an FTP
- Custom - if you have your own channel or a third party delivery solution you (or they) can create a custom delivery channel interface and XMLP will direct documents down that channel.
It even has the AS2 protocol implemented for your EDI messages. The APIs can rely on a configuration file to define servers, printers, etc or you can hardcode the information directly in your API call.
A very rich set of APIs that are being expanded with every release ... thats the good news. The bad news is that none of it is directly integrated into the concurrent manager, OA framework or forms ... if you want to use the functionality you are going to have to get into some java coding and customization.
As OAF is completely java anyway its not going to be a tough job to create some UI for folks to deliver docs.
As EBS11i uses Forms 6i, our options are a little limited to integrate the delivery APIs directly. We could create some plsql wrappers for the APIs ... thats been done by a couple of Apps teams already. Or we could just call a concurrent program from the form.
This is the most popular method of generating reports, lets just cover what is going on process wise in the concurrent manager today (11i.10.X) with an XMLP report.
- User selects an XMLP report to execute and enters the parameter values they want, the layout template, output format and language then submits
- Concurrent manager 'looks up' the concurrent program definition, finds the executable and calls it. This could be an XMLP Data Template, Oracle Report, pl/sql or any other extraction routine ... just so long as its getting XML data.
- Once the program has completed the Output Post Processor(OPP) comes into play. This is the new concurrent manager that handles the XMLP requests. It is passed a handle to the data file and calls the XMLP APIs to process the data to then generate the output based on the users choice of template, format, etc. The output document is then generated and the XML data is preserved.
- The user can then either view the document from the SRS forms and print locally or they might have asked that the document be printed directly to a printer. Hopefully the SysAdmin has set up PASTA to handle the document, pre-process it to a printer language and then pass it off to the printer.
Thats the current process in a nutshell. If we want to add delivery other than printing there are a couple of entry points for us to inject our own delivery options at:
Step 2: We can create a wrapper java concurrent program. This would be called by the concurrent manager instead of the current one. It would:
- Call the extraction conurrent program and wait for it to finish
- Call the XMLP formatting APIs to generate the output document i.e no OPP involvement
- Call the delivery APIs to deliver the document.
This approach has some advantages, you have complete control over everything that is going on, you can add parameters to the program so the user can select the delivery destination for the document at runtime, etc ... but there is a big disadvantage ... you are going to need a wrapper for every program or create a request set for every report containing the base report and the delivery program as a second program that can accept the request id of the first ... thats a hurdle in itself ... the programs in the request set are not 'aware' of each other and at runtime the CM does not pass info about them to each other e.g. request IDs ... been there done that ... its a nasty piece of code that has to make too many assumptions to work.Step 4
: We can create a virtual print destination in EBS that does not have a printer at the end of it but rather a shell or perl script that can take the document and deliver it down a channel based on the user's choice at runtime.
This has the advantage that we do not need to create custom programs, mess with the definitions, etc. It's another moving part but its at least everything we create is sitting at the end of the reporting flow.
The second option seems to be the most popular entry point for many third party delivery solutions. Im going to pursue this line of investigation over the next few postings.
Next ... getting into the delivery APIs!