The FileUtilsTasklet tasklet in SummerBatch provides a new mode : "Compare", that can be used to perform either text based or binary file comparison;

To provide access to these new facility, some additional elements have been introduced in the BluAge batch UML profile :

FileOperationMode.COMPARE: this new litteral has been added to the FileOperationMode enumeration. This new value can be picked to populate the mode tagged value of the "FILE_OPERATION_STEP" stereotype (see the Usage paragraph below).

Figure 6.1. FileOperationMode.COMPARE

FileComparisonMode enumeration: this enumeration lists the supported comparison mode for the FileUtilsTasklet;

Figure 6.2. FileComparisonMode enumeration

EqualityComparerType enumeration : this enumeration lists the supported text-based comparison modes (only taken into account if TEXT has been selected as FileComparisonMode)

Figure 6.3. EqualityComparerType enumeration

New tagged values for the "FILE_OPERATION_STEP" stereotype :

Usage

Using the compare mode is similar to other "FILE_OPERATION_STEP" usages : simply create the dedicated steps, using the "FILE_OPERATION_STEP" stereotype:

Figure 6.4. "FILE_OPERATION_STEP" Compare usage : creating the steps

and set the tagged values to suit your needs:

Figure 6.5. "FILE_OPERATION_STEP" Compare usage : default text compare setup

Figure 6.6. "FILE_OPERATION_STEP" Compare usage : IebCompr like text compare setup

Figure 6.7. "FILE_OPERATION_STEP" Compare usage : binary compare setup

then use them in the proper job diagram:

Figure 6.8. "FILE_OPERATION_STEP" Compare usage : using the compare steps in the job

The result of the file comparison is stored in the ExitStatus (the FileUtilsTasklet implements the IStepExecutionListener interface and uses the AfterStep method to return the ExitStatus). If the compared files are equals, the ExitStatus will be ExitStatus.Completed, otherwise the ExitStatus will be custom with "FILESNOTEQUAL" as ExitCode.

Feeding the steps with the proper files to be compared is achieved through the standard Settings.config mechanism; The key to be used is having the form "(Job Name).(Step Name in Job).sources" and the value to be given is a list of two semi-colon separated file paths pointing at the files to be compared.

e.g. : for the sample shown above, here is the corresponding Settings.config file content :

<?xml version="1.0" encoding="utf-8" ?>
<appSettings>
       <add key="BA_COMPARE_FILES.fileCompareTextDefault.sources" value="data/inputs/text1.txt;data/inputs/text2.txt" />
       <add key="BA_COMPARE_FILES.fileCompareTextIebCompr.sources" value="data/inputs/ieb1.txt;data/inputs/ieb2.txt" />
       <add key="BA_COMPARE_FILES.fileCompareBinary.sources" value="data/inputs/bin1.zip;data/inputs/bin2.zip" />
</appSettings>

In version 1.1.0 of SummerBatch, support for powershell scripts invocation has been introduced, using the Summer.Batch.Core.Step.Tasklet.PowerShellTasklet (and some other related code artifacts). To be able to use that feature, some additions neeeded to be made to the Blu Age batch UML profile.

"SHELL_SCRIPT_INVOCATION_STEP" stereotype has been introduced to be used on steps dedicated to invoke PowerShell scripts:

Figure 6.9. "SHELL_SCRIPT_INVOCATION_STEP" stereotype

Usage

Define one or several steps holding the "SHELL_SCRIPT_INVOCATION_STEP" stereotype,

Figure 6.11. "SHELL_SCRIPT_INVOCATION_STEP" Steps

and use them in the proper job diagram:

Figure 6.12. PowerShell Steps usage in job diagram

Note

Parameters owned by the Step will be used as parameters to be passed to the invoked PowerShell Script; the parameters values can be set at usage time in the job diagram (see the job diagram above : the input pins correspond to the values to be given to the DateTimeNow and scriptFile step parameters). Provided default values -- if any -- will be used if required. Given parameters are usable within the invoked PowerShell script; see the sample snippet below : [CmdletBinding()] Param( [Parameter(Mandatory=$True)] [string]$DateTimeNow, [Parameter(Mandatory=$True)] [string]$scriptFile ) ... Properties owned by the Step will be used as variables to be passed to the invoked PowerShell Script; a default value should be provided.

Specifying the script to be invoked by the PowerShellTasklet and the timeout to be used is achieved by filling the Settings.config file; The keys have the form :

E.g. - Here is the sample Settings.config file content for the sample shown above :

<?xml version="1.0" encoding="utf-8" ?>
<appSettings>
  <add key="BA_PS_INVOKE.PS_Invoke.SCRIPT" value="data/scripts/ScriptExitStatus.ps1" />
  <add key="BA_PS_INVOKE.PS_Invoke.TIMEOUT" value="100000" />
  <add key="BA_PS_INVOKE.TO_PS_Invoke.SCRIPT" value="data/scripts/ScriptTimeOut.ps1" />
  <add key="BA_PS_INVOKE.TO_PS_Invoke.TIMEOUT" value="12000" />
</appSettings>

	Warning
	For technical constraints, the ambient transaction needs to be suppressed before invoking the PowerShell script. Therefore, any required transaction support should be explicitely handled directly by the PowerShell script.

The Summer.Batch.Extra.Sort.SortTasklet used by "SORT_STEP" sterotyped steps is now able to handle multiple output files (vs. only one output file for SummerBatch version 1.0.0);

A new tagged value, named 'outfil' has been introduced in the "SORT_STEP" stereotype. This tagged value has to be filled with relevant information to activate the multiple outputs facility. Its content has to be a semi-colons separated list of configurations.

Each configuration is a comma-separated list of Commands, specified by the following syntax :"<COMMAND>=(<PARAMETERS>)" where COMMAND is the command name and PARAMETERS, its parameters.

The outfil tagged value support three commands: INCLUDE and OMIT to filter records, and OUTREC to format them. Each command support the same syntax as described in the SummerBatch documentation related section.

	Note
	If both the 'outrec' and 'outfil' tagged values are set for a given "SORT_STEP", the 'outrec' value will be ignored when generating code artifacts.

Usage

Stereotype a step with the "SORT_STEP" stereotype, feeding the 'outfil' tagged value with the convenient configurations:

Figure 6.13. "SORT_STEP" Step specification sample

and use it in the proper job diagram :

Figure 6.14. "SORT_STEP" Step in job diagram

To match the given 'outfil' value, the outputs specification has to be given as a semi-colon separated list of file paths, in the Settings.config file.

<?xml version="1.0" encoding="utf-8" ?>
<appSettings>
...
  <add key="BA_SORT_FILE.sort18.inputFiles" value="data/inputs/sort18.txt" />
  <add key="BA_SORT_FILE.sort18.outputFile" value="data/outputs/sort18-1.txt;data/outputs/sort18-2.txt;data/outputs/sort18-3.txt" />
</appSettings>

	Warning
	The number of given output files has to match the number of defined configurations in the 'outfil' value. Failing to do so will raise an early error at run time, preventing the proper job execution.

e.g. : modelized constants in a service interface

Figure 6.15. Modelize constants in Service interfaces

and here is the corresponding generated C# code snippet :

...
namespace Com.Netfective.Bluage.Services.CompositeEbcdicReader
{
    /// <summary>
    /// Service ServiceReadEbcdic
    /// </summary>
    public class ServiceReadEbcdic : AbstractService
    {
        private const string testConstant = "This is a test constant";
        private const int testConstantNum = 42;
        ...

e.g. : modelized constants in a business object

Figure 6.16. Modelize constants in a business object

and here is the corresponding generated C# code snippet :

...
using Com.Netfective.Bluage.Common.Tags;
using System;

namespace Com.Netfective.Bluage.Business.Batch.Datasourcewriter.Bo
{
    /// <summary>
    /// Entity DatasourceWriterBO.
    /// </summary>
	[Tag("DataAccess")]	
    [Serializable]
    public class DatasourceWriterBO
    {
    ...
        /// <summary>
        /// Constant Property DefEmailAddress.
        /// </summary>
        public const string DefEmailAddress =  "user@mycompany.com";
        ...

Setting the useVirtualMethods property to true for the com.netfective.bluage.dotnet.batch BSP in the BluAge launch configuration will ensure that all public and protected methods will also be marked as virtual (whenever possible), permitting to use performance auditing processes relying on code instrumentation mechanisms.

	Note
	The useVirtualMethods property defaults to true.

The Tag custom C# attribute will be applied to any generated C# artifact code provided the originating UML node has been properly tagged using the "UnityTag" stereotype (in the BluAge service UML profile).

The "UnityTag" holds a single tagged value, named "value" that contains a free-form String, used to identify the "domain of interest" for a given element. The content of the "value" tagged value will be used "as-is" in the generated code.

e.g. : tagging the "EmployeeService" with the "UnityTag" stereotype, valued with "BatchService" string

Figure 6.17. UnityTag stereotype usage sample

...
namespace Com.Netfective.Bluage.Services.Employee
{
    /// <summary>
    /// Service EmployeeService
    /// </summary>
	[Tag("BatchService")]	
    public class EmployeeService : AbstractService
    {...

Calls to logger are now delegated to a custom logger mechanism (see generated Log.cs and LogManager.cs classes); The loggerFactory, loggerImport and logger properties for the com.netfective.bluage.dotnet.batch BSP in the BluAge launch configuration can be used to customize the underlying used logger framework and the way the loggers are being named in the C# generated code.

Current default values are: