Publishing a document from the API

[kwesterlage]

How do I insert a document I have rendered using the API into a print job with a target of "Publish"?

[BobRichards]

You cannot use the document render API to directly perform a publish action. Instead, use the document API to render the file then attach the file to the order Attachments collection. Use the IAttachmentFolder, IAttachmentFile and IAttachmentItem interfaces located in the SoftPro.OrderTracking.Client assembly. Below is an example of attaching a file to an order from a prior post:

Code: Select all

IOrderStore os = sps.GetService<IOrderStore>();
IOrder order = GetMyOrder();

//add a new file
IAttachmentFile file = order.Attachments.NewFile("C:\\somefile.pdf");

//save the order to commit the attachment changes - attachments are part of the order
os.ApplyChanges(order);

[kwesterlage]

From a shell package, we were able to successfully publish/email/etc a document using the API by creating a custom PrintJobItem type (inheriting from the provided abstract class) and populating the PropertyBags of
the PrintJob and PrintJobItem with certain values.

We have logic in print job handlers that needs to be hit for any generated/attached documents (via the API or the Documents tab), so rather than re-inventing the wheel we want to tie into the existing workflow.
Is the code below an acceptable way to accomplish this?

Code: Select all

private void RibbonButton1_Invoked(object sender, EventArgs e)
{        
    try
    {
        var sp = GetService<SelectServer>();

        string orderNumber = "<T>";
        string documentTitle = "<T>";
        var renderedDocumentFormat = DocumentFormat.PortableDocumentFormat;
        
        var os = sp.GetService<IOrderStore>();
        var dm = sp.GetService<IDocumentManager>();
        var orderInfo = os.Orders.Where(x => x.Number == orderNumber).FirstOrDefault();
        var documentInfo = dm.Documents.Where(x => x.Title == documentTitle).FirstOrDefault();

        if (orderInfo == null || documentInfo == null)
        {
            if(orderInfo == null) Trace.WriteLine($"Could not find order {orderNumber}.");
            if (documentInfo == null) Trace.WriteLine($"Could not find document {documentTitle}.");
            return;
        }

        var order = os.OpenOrder(orderInfo, false); // Writeable order

        // Render the document                
        var rendererFactory = sp.GetService<IRendererFactory>();
        var renderer = rendererFactory.Create();
        var renderedDocument = renderer.Render(documentInfo, order, null).Export(renderedDocumentFormat);

        // Print Pipeline Integration
        var printJobFactory = sp.GetService<IPrintJobFactory>();
        var apiPrintJob = printJobFactory.Create(PrintJobTarget.Publish);
        apiPrintJob.Properties["Order"] = order; // "Order" is the only required PrintJob property (based on my testing)

        var item = new CustomPrintJobItem(this, renderedDocument, renderedDocumentFormat);
        apiPrintJob.AddToJob(item);
        apiPrintJob.Run();                                                                                                                         

        os.ApplyChanges(order);            
        os.CloseOrder(order);
    }
    catch(Exception ex)
    {
        Trace.WriteLine($"Error attempting to publish document. {ex.Message}, {ex.StackTrace}");
    }
    
}

public class CustomPrintJobItem : PrintJobItem
{
    public CustomPrintJobItem(IServiceProvider provider, Stream stream, DocumentFormat format) : base(provider)
    {
        Properties["Stream"] = stream; // This will also populate the "Binary" property
        Properties["BinaryFormat"] = format;
    }
}

[John Morris]

Can you provide more details on what you're trying to accomplish here? A little background of the requirements may help us to provide better guidance.

[kwesterlage]

Sure thing. Like I mentioned, we have code attached to existing print job handlers. This code performs a variety of actions, from marking tasks complete, sending the generated doc to external systems, taking a snapshot of data points in the order for historical purposes (for example: what did the order commitment data look like when we generated a commitment).

We were excited at the ability to render documents ourselves, but lost some of the buzz at the prospect of not having access to the print pipeline, which would require us to rewrite/rework a bunch of stuff that already works. Plus, we wanted the ability to manually render and have it show as a “Published” doc in the order, rather than “Attached”.

If your question was more focused on the larger goal of this project – we’re trying to give our users the ability to easily render individual or small sets of documents (Seller CD, Pre-Settlement Statement, etc.) without having to go into the Document button. We want it to utilize as much existing infrastructure as possible (both yours and ours, as mentioned above regarding existing code) to eliminate need for rewrite or rework.

[JDavis]

Did you ever get any more info on this topic? We would like to do the same thing - render documents via API by not going to the documents tab.

[ckootg]

Bump

[BobRichards]

Please see previous post: 4.1 API example for docs/reports

[ckootg]

Thanks for the link, but I was looking for more information on integrating the print handlers. We store our documents in our own document management system, not in SoftPro, so we use the print handler to send the rendered document to the document system. We are also looking to programmatically post, print, and publish transactions, which also requires the print handler to send the rendered document(s) to our document system. Any ideas on incorporating the print handlers?