Skip to main content
Feedback

Return Documents step

The Return Documents step is placed at the end of a document path and returns the documents to the calling source point.

Return Documents icon

The calling source point is one of the following:

  • The parent process

  • A web service client application

When you create a Return Documents step, you should give it a custom label. The label is a user-defined name that identifies the document type(s) that reach the step during a process execution. It is also important when used with a Process Call or Process Route step. If a custom label is not entered, Return Documents appears on the step.

Returning documents to the parent process

Depending on your integration scenario, you might want to organize your integration across multiple processes, where each process performs a specific task. This approach also helps to control process design space and limit the number of steps per execution. You can have a primary process that triggers one or more subordinate processes via the Process Call or Process Route step. It can also be referred to as a parent-child process relationship.

When using the Return Documents step in a child process, any documents that reach the step are batched and returned to the parent process that calls the child process. After the Process Call step, the documents proceed down a new branch. This new branch extends from the associated Process Call step for each new Return Documents step that is added to the child process. The Return Documents label is important in this case, so you can route your documents accordingly, as the labels will be visible along each branch extending from the parent process.

For Process Route steps, you can associate Return Document steps with the Return Paths that you define in the Process Route component. For this reason, it is important to give the Return Document steps unique and meaningful labels.

note

The Start step has different actions that affect how the Return Documents step and child processes affect the process flow and logging on the Manage menu. Ensure that you are using the proper Start step action along with the parent Process Call or Process Route step to return the necessary responses.

Returning documents to a web service client application

When the Services Enablement feature is enabled in your account, you can build a Web Services Server listen operation into your process to accept requests in real-time from client applications. There are cases where web developers want a synchronous response when invoking a web service process. The Return Documents step is the only step that can be used to batch all documents that reach it during the process execution and return the response data to the web server client to end the conversation.

note

Only one Return Documents step should be used per process to return a response to the client. Consider building other web service processes to return unique responses for each object/action that you want to integrate. Review the Web service processes topic to learn how this step is used to send synchronous responses to an external calling application via the Runtime's embedded web server.

Return Documents step example

The Return Documents step reacts differently when compared to other process steps in regards to flow execution. No matter how many different paths need to finish throughout the course of an execution, the Return Documents steps "wait" until all possible documents reach the step and then returns the documents accordingly via one of the use cases above. Instead of returning documents one by one to the source calling point, the step batches all documents first.

The example below describes a case where this is useful, so you can pause the processing for specific data scenarios.

Assume that you need to use the HTTP Client connector multiple times within a process with different operations. Each time it executes, it retrieves a different data type. Normally, the returned files go down each path after the connector uniquely and are outputted to a destination as single documents.

You can use a child process call to gather all of the relevant data together. With this call, it is possible to retrieve files from multiple sources and then "wait" for them in the parent process.

Here are the general steps to follow to build this type of process:

Creating a child process

  1. To create the child process that gets multiple files via the HTTP Client Connector, set the Start step to "Data Passthrough".

  2. Add a Branch step with the number of branches equal to the number of files that you want to get.

  3. On branch 1, add a Connector step that does an HTTP GET. This retrieves the file from the web site.

  4. After the Connector step, attach it to a Return Documents step labeled with an informative name, such as "Results".

  5. On branch 2, add a Connector step that does an HTTP GET for the other file.

  6. After the Connector step, attach it to the same Return Documents step.

  7. Save and close the process. (Or you can run the process in Test mode to make sure that it successfully retrieves the files).

    Child process using a Return Documents step

Creating a primary process

  1. To create a primary process, set the Start step to "No Data".

  2. Add a Process Call step and select the child process.

    Once selected, a line emerges from the Process Call step with the label of the Return Documents step in the child process Call (in this case, "Results"). This line contains your combined results.

  3. Run a process to combine the files and send them to the proper destination.

    Primary process using a Return Documents step

  4. You must deploy the processes to a Runtime to test the functionality of the Return Documents step. The Return Documents step is not available in Test mode. Review the Connection Licenses topic to ensure that you can deploy effectively.

On this Page