Compression Service - Processing .zip archives with IBM Sterling B2B Integrator.

Body

Processing .zip archives.

I am going to focus on using the Compress Service to pull files out of .zip archives and process them.  This is also called decompressing or inflating the files.

When the Compression Service decompresses a .zip archive, it works on the PrimaryDocument of the business process.  So you need to make sure the PrimaryDocument is the .zip archive that you want to decompress.

The arguments that are used in the decompress are

compression_action

decompress_result

file_name

bpml_name

compression_action

To pull files out of a .zip archive, set the compression_action parameter to Decompress.  This tells the Compression Service to take the PrimaryDocument and decompress it.

decompress_result

You can set this to either primary_doc or start_bpml. 

If you set this to primary_doc, the Compression Service will pull one file out of the .zip archive, and make that document the PrimaryDocument.

If you set this to start_bpml, the Compression Service kicks off a business process for each file in the .zip archive.

file_name

This is used when you set compression_action to Decompress and decompress_result to primary_doc.  Set file_name to the file in the .zip archive that you want to extract.  It will take this file and make it the PrimaryDocument. 

In the example below, the Compress Service pulls a single file named MyFile.txt out of a .zip archive and makes it the PrimaryDocument

    <operation name="Compression Service">

      <participant name="CompressionService"/>

      <output message="compressionInputMessage">

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

        <assign to="compression_action">Decompress</assign>

        <assign to="decompress_result">primary_doc</assign>

        <assign to="file_name">MyFile.txt</assign>

      </output>

      <input message="inmsg">

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

      </input>

    </operation>

If you leave file_name blank, the Compression Service will pull the first file out of the .zip archive and make it the PrimaryDoc.  A use case for this is processing a .zip archive with a single zipped file.  You don’t need to know the file name beforehand in this case. 

For example:

    <operation name="Compression Service">

      <participant name="CompressionService"/>

      <output message="compressionInputMessage">

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

        <assign to="compression_action">Decompress</assign>

        <assign to="decompress_result">primary_doc</assign>

      </output>

      <input message="inmsg">

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

      </input>

    </operation>

bpml_name

This is used when you set compression_action to Decompress and decompress_result to start_bpml.

This holds the business process name that you want to kick off.

In this case, the Compression Service kicks off an instance of the business process in bpml_name for each file in the .zip archive.  It will make that file the PrimaryDocument of the new process.

The child processes are all kicked off asynchronously.  This means that the process running the Compression Service continues and does not wait for the child processes to complete.

One use case for this is processing a .zip archive that has 1 or more files sent.  For example:

    <operation name="Compression Service">

      <participant name="CompressionService"/>

      <output message="compressionInputMessage">

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

        <assign to="bpml_name">PROCESS_DOC</assign>

        <assign to="compression_action">Decompress</assign>

        <assign to="decompress_result">start_bpml</assign>

      </output>

      <input message="inmsg">

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

      </input>

    </operation>

message_to_child

Using bpml_name in the Compression Service works very much like the Invoke Sub-Process Service using ASYNC for INVOKE_MODE.  The child processes kicked off show up in the Business Process search as child processes of the process running the Compress Service.  For example, you can use the BP Metadata service in the child process to see information about the parent process which ran the Compression Service.  You can also use the message_to_child tag to send data to the child processes. 

For example, to populate ProcessData in all of the child processes:

    <assign to="message_to_child/TAG1">Data to send to child</assign>

    <operation name="Compression Service">

      <participant name="CompressionService"/>

      <output message="compressionInputMessage">

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

        <assign to="bpml_name">PROCESS_DOC</assign>

        <assign to="compression_action">Decompress</assign>

        <assign to="decompress_result">start_bpml</assign>

      </output>

      <input message="inmsg">

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

      </input>

    </operation>

The child processes will at start with ProcessData like:

<ProcessData>

  <TAG1>Data to send to child</TAG1>

  <PrimaryDocument SCIObjectID="siqaserver1:node1:15e86ca10cc:1788"/>

</ProcessData>