Creating multiple documents out of one record "on demand"

rorso · 2024-09-04T09:36:58+00:00

There was an error rendering this rich post.

I got the task to occasionally create TWO documents out of ONE Empower file with "essentially the same content but …"

I have no hint to do this when creating the Empower document in the first run. This is a decision in the "Interview page". The user may decide to create both a "long" and a "short" document that share 99% of their definition.

Here are my current findings:

The API call for fulfillment (or creation) would return multiple outputs of the same document, like PDF + Empower without problem.
Likewise I can receive multiple documents, if my trigger file contains multiple "Customers", but these do certainly end up in multiple Empower documents too.
I cannot run a single customer twice in one run.
I'd like to avoid duplicationg the structure, as it means to do every change twice or the documents drift apart.
I obviously cannot "preview" multiple documents while in Empower
I cannot communicate the user choice to the calling application, to get the document "fulfilled" twice with different parameters
I cannot rely on a rule that does run during fulfillment. Yes I can create one of two choices, but I cannot just "run this document again with different settings".
Creating a second output connector does not help me out.

In "Streamserve", I would just set a variable and call the output process (Storyteller) twice, either merging the documents or creating separate ones. No brainer.

But with "Exstream"? 😱

Find more posts tagged with

Note:

If there are Accepted Answers, those will be shown by default. You can switch to 'All Replies' by selecting the tab below.

Accepted answers

All comments

Steven Cheal

Hello,

It's not clear if you are using Communications Designer or Design Manager for designing the interactive applications, but there are a couple of concepts in Exstream/Empower that may help you here:

Recipient processing. This is the ability to generate a set of 'documents' for a single 'customer' record, and then produce copies or subsets of copies that will go to multiple end recipients. This functionality is best suited to use case, where you have just a few end recipients, such as the customer's agent and or attorney copies. This works with Interactive (Empower) such that you can pass the recipient data in either the initial Engine run, or fulfillment Engine run. There is documentation on this functionality in The Designing for Exstream and Designer for Empower sections of the reference guides.
Note that for Communications Designer application this functionality is not generally available, and will be available in an upcoming version.
One-to-many fulfillment. This functionality is intended for use cases, where you want to create a single Interactive document, designed to be fulfilled to multiple end 'customers'. For example, you need to create a generic letter, which is personalized with unique customer details to hundreds, or thousand of end recipients. In this case, variables will be updated, and business logic can be executed, for each end customer during fulfillment processing.
For information on this functionality, please see the section "Fulfillment scenarios for Empower documents" in the Designing Empower documentation.

Hope this helps, please respond to this post if you cannot find the documentation I am referring to.

Steve.

rorso

Thanks for your reply.

The application is a one to one. Just one "customer" yields one document. It's a Quoting application. The quotes are massively "hand crafted" in Empower and the initial run is just an "educated guess". Documents live in Empower for weeks and months before the content is customer-ready. This is highly interactive.

In the meantime there might be several changes to the original quote record (which we fetch live from Empower).

But eventually the management decides to need two sets of "this quote" with certain information skipped in one expression, i.e. hand over two variants in fulfillment instead of just one. So they can archive a "technical quote" along with a "business quote" as two separate files.

Development is done in Designer with a rudimentary Communications Builder shell to get it deployed.

The document(s) is fetched via Exstream API call /communications/create for the Exstream "fulfillment application" i.e. fetch the Empower file and render the placeholder content.

rorso

https://forums.opentext.com/forums/developer/discussion/comment/969345#Comment_969345

I take every help I can get. If you have a hint about the documentation, where I could find more ideas how to create several versions of the same document on demand with "Exstream Designer", then please…

Steven Cheal

Hello,

Most Interactive (Empower) use cases we see, typically involve edit>export>fulfill, in a matter of days. The use case you refer to, is a little outside the norm, and I'm not sure here is a straightforward way to achieve that with current server based functionality. Interactive does not store multiple versions of a single document, it can produce variants in final output by triggering business logic as I mentioned.

Cloud Native has functionality which allows you to create an Interactive document, and have the user import Interactive content directly from an asset store, where content authors have been maintaining and updating content as business requirements change. I realize this does not help your immediate business requirement.

Regards,

rorso

Well. that's what my customer does and what he bought from OT. I just have to try my best to get the results he wants with what is available. 🙄

I know how to do variants during fulfill, but it's just "one variant", not "more than one document at once". So it may be needed to call fulfillment twice with different settings. But as far as I know, it's pretty tough to impossible to submit additional parameters for the fulfillment in the API call. Something that then can get used inside the document rules.

It seems to be either "completely outside, not accessible from within" (meta data) or "completely inside, not possible to change from the outer space" (variables).

The installation in fact IS in the OT cloud (limiting physical access and configuration). But we cannot use the Cloud-Native interactive content methods. They are too "manual" and do not mix and match well with the Designer layout, because they cannot share the same container and thus cannot get inserted into Designer "editable paragraphs".

Steven Cheal

Hi,

You can conditionally rerun business logic and alter variable values in fulfillment by using the final engine timing for rule execution and variable substitution, in either the Empower settings or at object level.

rorso

I already do this for managing a "DRAFT" overlay that should not be visible in fulfillment.

But I found no clue how to "process the document twice" to get two documents in the output from within Engine.

On the input side of the fulfillment, I just get a Document-ID that gets translated into an EMPOWER-file with the "Empower input filter" (*.jar) in Communications Builder. It's like pointing the driver file of the fulfillment application to a stored *.mpw file when running locally.

Next time I get control over the process in Communications Builder is when the the Engine output hands over "the PDF" to the CB output connector. All processing is done within the one Engine-call.

If I can convince the fulfillment application to run "the document" a second time on demand, I eventually could set different values for that one. But other than with a reference API call, that I can trigger at any time with some code, I found no hook to "loop the application run".

I can call the fulfillment API call twice and still have the problem to decide, which "version" this should render, as the API call does not allow for additional modifiers other than the Empower-Document-ID. So I'm essentially bound to variable values that get loaded with "the document" i.e. they are the same each time.

With CB, Message processing and Storyteller, I would just issue two "callproc()" to get "the document" twice and I can certainly set values before doing it the second time.

I even tried to define both variants within Designer and a variable to enable or disable one. But this would eventually result in having the same document twice in Empower and all manual changes have to be done twice, as they are just "other pages" and the content is not synced, even if I use the same paragraph links.

I currently work with the customer on a "solution" to call a pre-defined web service on each run to get a state-information. The calling application first has to define the state, call the fulfillment, await the result, change the state and call the fulfillment again. That way we get different "state" for the same document that we can use for rules. But that's quite slow and "ugly". 😱

But I still might just run the wrong direction, missing something obvious.