Merge documents

Below are the services and adapters that will help user to merge or concatenate two documents into one document in Sterling Integrator.

MergeDocument Service: This Service has been introduced to merge or concatenate two documents into one document. It takes two primary documents as input, and the resulting document will be placed in primary document.

<process name="Test_MergeDocumentProcess">

                <sequence name="main">

                                <!-- To pick/collect 1st file named file101.txt -->

                                <operation name="File System Adapter">

                                                <participant name="FileSystemAdapterInstance"/>

                                                <output message="FileSystemInputMessage">

                                                                <assign to="." from="*"/>

                                                                <assign to="Action">FS_COLLECT</assign>

                                                                <assign to="deleteAfterCollect">false</assign>

                                                                <assign to="filter">file101.txt</assign>

                                                </output>

                                                <input message="inmsg">

                                                                <assign to="." from="*"/>

                                                </input>

                                </operation>

                                <!-- Assign the primary document to process data i.e.doc1  -->

                                <assign to="variables/doc1" from="PrimaryDocument/@SCIObjectID"/>

                                <!-- To pick/collect 2nd file named file202.txt -->

                                <operation name="File System Adapter">

                                                <participant name="FileSystemAdapterInstance"/>

                                                <output message="FileSystemInputMessage">

                                                                <assign to="." from="*"/>

                                                                <assign to="Action">FS_COLLECT</assign>

                                                                <assign to="deleteAfterCollect">false</assign>

                                                                <assign to="filter">file202.txt</assign>

                                                </output>

                                                <input message="inmsg">

                                                                <assign to="." from="*"/>

                                                </input>

                                </operation>

                                <!-- Assign the primary document to process data i.e.doc2  -->

                                <assign to="variables/doc2" from="PrimaryDocument/@SCIObjectID"/>

                                <!-- MergeDocument service takes the 1st file from doc1 and 2nd file from doc2, merges the contents of 2nd file at the end of 1st file -->

                                <operation name="MergeDocument">

                                                <participant name="MergeDocumentInstance"/>

                                                <output message="MergeDocumentInputMessage">

                                                                <assign to="." from="*"/>

                                                                <assign to="document1" from="'doc1'"/>

                                                                <assign to="document2" from="'doc2'"/>

                                                </output>

                                                <input message="inmsg">

                                                                <assign to="." from="*"/>

                                                </input>

                                </operation>

                </sequence>

</process>

Let’s say the content of 1^st file is ‘File name is file101.txt’, and 2^nd file content is ‘File name is file202.txt’. The resulted document content will be ‘File name is file101.txt File name is file202.txt.

File system adapter: File system adapter (FSA) can also be used to merge documents. This is a preferred way of merging documents when writing or reading files from disk (file system) is allowed. When FSA used to merge documents it can be done two ways.

1. During Extracting: In order to merge documents during document extraction (writing files to disk), below parameters need to be configured.
• appendOnExtract – Set to ‘Yes’, this configuration will allows user to append data to the existing file, instead of creating new one. As it’s going to append to the existing file the file name must be unique. Configure ‘assignedFilename’ parameter to give specific file name to file.
2. During Collecting: In order to merge documents during document collection (reading files to disk), below parameters need to be configured.
• concatenateFiles – Set to ‘Yes’, this configuration will allows user to concatenate files during collecting multiple files. The contents of all non-zero byte files will be concatenated to a single file and placed as the primary document. This parameter configuration will work when FSA is configured in non-bootstrap mode and the parameter ‘collectMultiple’ is set to ‘Yes’.

Debugging your Map?

Are you looking to debug your map to know where it went or why it's giving unexpected results? Then this is for you.

Debugging helps in many ways

• To understand the complex logic written in a map.
• To know the value of a variable at any point of time.
• If you are not sure why a particular field is not giving expected result.
• To check if the condition is working as expected or not

Below are the few ways to debug your map. I personally prefer to use ‘writeblock(<string>)’.

Writeblock(<string>) extended rule:

This function prints a new line on the output side (map result) with the information or data that was passed as an argument. This extended rule is the most simplest to use and find out what’s happening. All you need to write the writeblock extended rule where you feel like, and pass on the information that you would like to see on output.

Usage:

               writeblock(String strVariable);

               Where -

                              strVariable – String message that you would like print on output.

Example:

                String[100] strMessage;

                strMessage = “Test writeblock function..”;

                Writeblock(strMessage);

                writeblock(“Test writeblock() function….”);

Note: This function will take only string as an argument, when you want to print non-string values those should be converted to string.

Pros:

• Simple to use.
• Output message can be easily located, as you can see it along with output.
• No need to enable or disable any logs.
• No need to go to any specific location or interface to see messages.

Cons:

• Only string values are supported, all other data types need to be converted.
• By mistake if this code is migrated to live environment, it’ll cause issues.

MessageBox(<string>, 0) extended rule

This function prints the information that was passed as an argument on to translation log.

Using this function is simple as there are no restrictions on data type. However to see output one should access log files through Admin interface or file system. If the log was disabled or turned-off, then it won’t give any result.

Usage:

messagebox(String strMsg, 0); or 

messagebox(<fieldname>, 0);

Where –

strMsg – String message that will be printed to log

0 – Another mandatory parameter

fieldname – Refer any field, that would like to see its value on log file

Example:

                String[100] strMessage;

                strMessage(“Test MessageBox function…”);

                messagebox(strMessage, 0);

               

                messagebox(#0098, 0);

Pros:

• No restrictions on data type.
• Even if this code migrated to it’ll no show any impact on output, but it fills translation in case if it’s enabled.

Cons:

• Translation log needs to be turned-on to see the messages.
• All the maps that are running in system keeps writing their respective entries in this file.
• Developer must access this log using Admin interface/Dashboard or through file system.
• Hard to find or locate your messages, as there will be many other entries by other maps.

Push it to a field on output side.

The other way of debugging your map is to create a dummy field/element on output side and pass the information to it. Before migrating code to live environment these extra fields or elements needs to disabled or removed from map.