In production applications, it's often good practice to keep 'audit trails'. To accomplish this, we need to address a few issues such as where to store the audit files, how to generate a unique filename for each audit run that prevents overwriting the previous run, what data to output, and how to output the data. Addressing the storage issue is fairly easy and is as simple as establishing a disk storage path for your audits. 

In this example we will use:  file:///c:/myproject/audittrails. 

To assist in the generation of the unique file name we will employ some PROJECT variables. One variable will hold the disk storage path and one will hold a time stamp to be appended to the file name for uniqueness. The actual filename will be created in the component doing the logging thus adding flexibility to the scheme on a component by component basis. In addition, a third PROJECT variable will be used as a switch to turn auditing ON or OFF using a Decision action. 

The variable to hold our final fully qualified audit path and file name URL will be created during component execution using a Function action as follows:

 Next we map the current date into the Todays_Date PROJECT variable. 

Then we use another Map action to generate the actual filename. This second Map action takes Todays_Date and uses the Content Editor to assign the base filename (set_edi_paid_), customize the time stamp to our liking, and append the time stamp to the filename. Then the Map action output or target dynamically creates a PROJECT variable called AuditFileName to hold the filename portion of the final fully qualified audit file. 

Note that the name for the Audit file (set_edi_paid_) is prepended as static text to the results of the timestamp transformation using the Insert Text button on the Content Editor dialog. This is where you would change the base file name if you were to copy these actions to another component for auditing. 

Lastly, a Function action concatenates AuditFilePath with AuditFileName to create a fully qualified file URL for use by the XMLInterchange action that will do the actual write for the audit file. Note that the dynamically created PROJECT variable AuditFileName will be destroyed when the Service calling this particular component is finished executing. (note: you can also dynamically set the Write_Audit switch at run time by passing in a parameter to the service containing this component.  The first task of the service would be to update the Write_Audit variable in the PROJECT DOM. This allows you to package in some debugging tools in the deployed environment)

    The result of the two Map actions and the single Function action is a variable called AuditFileName with a value of:             

    file:///c:/myproject/audittrails/set_edi_paid_Aug3100_120412.xml 

This variable will be used by our XMLInterchange action below. 

The data to output as the content for the audit is really up to you and your application needs. The only requirement for this example is that the data be in a DOM for use by the XMLInterchange action. For audit purposes you may want to add a Temporary DOM named Audit to your component and Map information into it during the execution of a component. Alternatively, you can set up a collection of audit data as PROJECT variables. For our example we will simply use the Output DOM. 

Once your audit information is in a DOM and you've created an audit file URL, you are ready to create the audit file with an XMLInterchange action as shown below: 

The final action model for our audit trail example is shown below: