Does Archiver Do Dynamic Value Mapping? <$if isTrue(IsSkeptical)$>I Don’t Think It Can.<$else$>Absolutely!<$endif$>

A user in the Oracle forums recently made a rather blanket statement that “dynamic changes are not possible with Archiver”. 

Never being one to shy away from a challenge, this post shows that import maps in Archiver can indeed be designed to be dynamic. 

It’s not readily apparent, but the admin applets are largely capable of utilizing Idoc Script, which in itself is very dynamic.  Coupling script with components is a very powerful way to build very complex logic to compute values in a mapping operation.  You don’t necessarily need a component, as you can simply key all the script logic directly into the value map box, but it’s easier to edit and compose the code logic outside of the applet.

To demonstrate this, first create an archive, and select a document to export, and export it. 

Looking at the item’s document information page, the document’s info looks like this.  Note that the expiration date is blank.
 

As an initial example, let’s set the expiration date to 7 days from the current date.

 

Open the archive’s “Import Maps” tab.  Select the “Edit” button located beside the “Value Maps” section.

Select “Expiration Date” from the field list.  In the “Output Value” box, enter “<$dateCurrent(7)$>” as shown in the next screen print, and click “Add”.  The value map is added as shown in the second screen print.   Click “Ok” to exit.

 

Now import the document exported earlier.  The expiration date is now set for 7 days from the date/time the import was executed.

 

Let’s do something a bit more complex by building some logic into a component to build a value for assigning to a document.  This example will be used to add comments to the document from the first example.  Again, note that the comments are blank for the document.



Start with creating a component with a resource file.  In the resource file, let’s create a dynamichtml include called “myExternalLogic”.

Let’s discuss a couple of things about the include that was created. 

First, note the “trimtext” directive added to the include definition.  This tells the system “whatever the result of the include is, trim the leading and trailing white space”.  This is good, since eventually the computed value will be put into a metadata field, and the extra whitespace may be an issue.  Secondly, note the trailing <$strResult$>.  Think of this like an ECHO statement – we’re just printing out the result for the import process, and it is necessary to actually get the value passed.

In the import map section, now add “Comments” as the field, and enter the text “<$include myExternalLogic$>” in the “Output Value” box as shown.  Click “Ok”.

Importing the document again populates the comments section with “some random text” as shown.

The logic can easily be more complex.  Let’s add another variable to the calculation.  Add <$myTemp=1$> to the import map as shown.

Now in the component resource, edit the resource to use this new value in the calculation.

Now the comments are populated based on the value of the variable “myTemp”.

The possible variables could also include environment variables, local variables, or other active values in the current row of the result set, which makes this VERY powerful.  Any constructs used in a dynamichtml statement are valid.  

For example, to put the current document type into the comments field use <$strResults=#active.dDocType$>.  It’s also possible to execute services in this manner to retrieve other data, although if field names are identical in the executed service, there is a risk of data pollution.

This is a really simple example of how Archiver is definitely “not static”, and can easily handle complex calculations.