FRENDS

FRENDS COBALT MANUAL

CONTENTS

TERMS OF DELIVERY AND USE

These Terms of Delivery and Use (“Terms”) shall apply to FRENDS Cobalt software in object code form and any related documentation (“Product”) ordered and delivered to the licensee (“you”) by Frends Technology Inc (“FRENDS”).

You agree to be legally bound by these Terms by selecting the accepting option below or by using the Product. If you do not agree to these Terms do not download or use the Product.

General

You may download an evaluation version of the Product, in which case you are entitled only to evaluate the Product before purchasing a commercial version of the Product. When you download and purchase the commercial version of the Product, you shall first pay an applicable license fee with your credit card or other payment methods available. After the due payment, FRENDS shall deliver you a registration code, which enables the operation of the Product.

It is important, and therefore you represent and warrant, that the identification and contact information you have provided to FRENDS in connection with your order for the Product is accurate and complete. Otherwise FRENDS may not be able to verify your payments and deliver you the necessary registration code. All identification and contact information will be subject to the privacy policy of FRENDS.

You shall be responsible for acquiring at your own expense all necessary software, equipment and telecommunications for using the Product.

The Product is neither intended nor fit for the use of consumers but companies only. Furthermore, the Product is not designed to be fault-tolerant and therefore it is not intended for use in hazardous environments that require fail-safe performance, such as in connection with life critical applications and systems.

Licenses of Evaluation Version and Commercial Version

You have a limited, non-exclusive and non-transferable right to install and use one (1) copy of the Product on one (1) server or workstation.

If you have downloaded an evaluation version of the Product, you are entitled to use the Product, free-of-charge, strictly for the sole purpose of evaluating the features and usability of the Product, during a period of thirty (30) days from the day you downloaded the Product.

If you have downloaded a commercial version of the Product, you are entitled to use the Product, subject to the payment of an applicable license fee, strictly for your internal business purposes only.

In addition, you shall not (i) make other one (1) back-up copy, modify, work around any technical limitations, decompile, disassemble, reverse-engineer, or create derivative works based on, the Product; or (ii) assign, transfer, sublicense, rent, or otherwise distribute or make available, the Product or your limited right to use the Product; save to the extent that otherwise expressly provided for by mandatory provisions of applicable law.

No Warranty, New Delivery

The Product is licensed strictly “AS IS” without any warranty, express or implied, whatsoever, including but without limitation to warranties of merchantability, fitness for any particular purpose, performance or non-infringement. You shall assume the entire risk for your use of the Product. FRENDS shall have no obligation to provide you with maintenance, support or other consulting services, or upgrades of the Product.

However, if you have downloaded, and duly paid for, the commercial version of the Product, but there have been errors in the transmission that prevent the operation of the Product, and you are not able to reload the Product, you should inform FRENDS without delay. FRENDS shall then make the Product available for a new downloading over Internet, or send the Product via email or ordinary mail to you. In case of an ordinary mail, you shall bear the costs of shipping.

Property Rights and Confidentiality

Title, ownership and all intellectual property rights to the Product belong exclusively to FRENDS or any supplier of FRENDS. You are granted only a limited right to use the Product.

Aspects of the Product, including the specific design and structure, and registration codes enabling the use of the Product, are confidential and trade secrets of FRENDS or any supplier of FRENDS. You shall maintain such information as strictly confidential, and shall not disclose them to any third party or use them for any unauthorized purpose.

Limited Liability

Due to the fact that the Product is licensed to you strictly on an “AS IS” basis without any warranty, to the maximum event permitted by the applicable law neither FRENDS nor any supplier of FRENDS shall be liable for any damages whatsoever, including but without limitation to direct, indirect, special, consequential, punitive or incidental damages, and loss of revenue, profit or data. In any case the maximum liability of FRENDS shall be EUR 100.00. These limitations of liability constitute an essential part of these Terms. However, should your authorized use of the Product violate any third party intellectual property rights, FRENDS shall compensate you for the license fee you have paid provided that you inform FRENDS of the suspected or actual violation without undue delay and discontinue the use of the Product.

Laws and Forum

This Agreement shall be governed by substantial laws of Finland. Any and all disputes arising out of these Terms shall be intended to be settled amicably. In case an amicable settlement is not reached, the dispute shall be submitted to the District Court of Helsinki, Finland.

Please note that you must use the Product in compliance with applicable export and import laws, regulations and rules, if any.

Termination of License

Each license to the Product shall terminate immediately and without notice in case you are in breach of these Terms, with the exception of such provisions that by their nature are intended to survive the termination of these Terms. Furthermore, FRENDS shall not be obligated to refund the license fee to you.

Entire Agreement, Amendments

These Terms constitute the entire agreement between you and FRENDS, and shall supersede any previous written or oral agreements and understandings, in relation to the subject matter of these Terms. Any and all amendments to these Terms shall be made in writing and expressly accepted by both you and FRENDS.

OVERVIEW

FRENDS Cobalt is a Windows Workflow Foundation (WF) solution built on top of FRENDS Iron for scheduled transfer of files.

With FRENDS Cobalt you can easily automate recurring file transfers within the enterprise. The transfers are configured as a single XML structure from the FRENDS Iron management console. The same console can be used to run and monitor the transfers as well.

FRENDS Cobalt can read files from and deliver files to file system, FTP, FTPS and SFTP servers. Text file encoding can be changed and XML files can be converted using XSLT in message processing steps. Files can naturally be transferred without conversions as well.

Possible errors in FRENDS Cobalt executions are reported to the Windows EventLog and in FRENDS Iron as well, so operators can take action as required. There is also a sample transfer log database that can be used to log transfer details and show reports on failed and successful transfers. In addition, FRENDS Cobalt uses Log4Net for logging purposes that can be configured to e.g. send reports as needed.

MAJOR CHANGES BETWEEN VERSIONS

1.5
Initial public version
1.6
Minor bug fixes. Changed SourceOperation.Rename to also accept directories, so you can move and rename source files after they have been transferred. Now SourceOperation.Move only accepts directories: it can only be used for moving source files with the original names.
1.7
Added extension API.
Major changes to message processing steps: backups, conversions and custom processing are now done in the message processing steps. Note that this change requires you use Iron 2.4 SR1 or later.
Updated Rebex.Net assemblies to version 1.0.3723. See section "Upgrading" for details on what this means for upgrading from previous versions.
1.8
File endpoint now supports specifying username and password for remote file shares.
Message processing step extension API changed. More details added to step's transfer context, see extension API for details. Message processing steps and endpoints need to be rebuilt, see Known issues section for more details.
Cobalt workflow supports FRENDS Iron's new ActionSkipped state. See FRENDS Iron documentation for more information on ActionSkipped state.
Source and destination folders support using macros.
Destination folders can be configured to be created during transfer.

INSTALLATION

FRENDS Cobalt is installed and configured with FRENDS Iron.

1. Install FRENDS Iron

Unzip the FRENDS Iron package and run the Windows Installer installation package. Check the prerequisites and follow the instructions in readme.rtf

The installer installs the needed libraries and executables. After installing, you need to run the FRENDS Iron Configuration Tool to set up the Windows services, databases and other settings. The installer suggests you do this at the end of the installation.

2. Configure FRENDS Iron

FRENDS Cobalt is configured together with FRENDS Iron with the FRENDS Iron Configuration tool. For details on this, see the FRENDS Iron configuration tool manual and the FRENDS Iron readme.rtf.

In order to configure FRENDS Cobalt, you need to make sure the checkbox for "Import FRENDS Radon/Cobalt sample routines" is checked. This will import the sample routines, tasks and CPs, as well as copy the needed assemblies to the FRENDS Iron installation directory.

Check the Import checkbox in FRENDS Iron configuration wizard

If previous versions of the assemblies are already installed in the FRENDS Iron directory, the configuration tool will ask for confirmation before copying the files. If you choose to continue, the existing assemblies will be overwritten. In this case, if the sample tasks are also installed, new copies of them will be imported using new names like "FRENDS Cobalt Sample Routine (2)"


3. (Optional) Logging file transfers to database

You can log details of the file transfers and the transferred files to a database. However, because reporting needs vary greatly, the database logging is not turned on by default. To turn it on:

  1. Create the needed database structures to a database. Logging expects there to be a stored procedures named sp_InsertTransferInfo and sp_Signal_TransferComplete. For details on these, see the section Stored procedures below

    You can create the sample database structures with the included SQL script file CreateTransferLogDatabaseStructure.sql, as described in the guide SampleTransferLogDatabaseAndReportsInstallation.html

    Please note that the sample database tables and reports that come with FRENDS Cobalt are only meant as samples on how to use database reporting. You should review the database scripts and modify them if needed.

    For instance, the sample stored procedures will automatically remove data older than one month. If you want to change this period, or change the simple way the cleanup is currently done, you need to change the stored procedure.

    In any case, you should make sure the database is backed up and cleaned up regularly.

  2. Give the FRENDS service user write access to the database and rights to execute the stored procedure, if needed
  3. Add the connection string to the FrendsAccService.exe.config file's <connectionStrings> section, with the name Frends.Cobalt.Properties.Settings.FileTransferLogConnectionString. For example:
    <add name="Frends.Cobalt.Properties.Settings.FileTransferLogConnectionString"
          connectionString="Server=(local);initial catalog=FRENDS;Integrated Security=SSPI"
          providerName="System.Data.SqlClient" />

Stored procedures

If the database transfer logging is enabled (the connection string is defined), Cobalt calls two separate stored procedures:

If calling either of these stored procedures fails, Cobalt will retry the write once after one second, if it fails again the failure is logged with the same logger as other workflow errors, by default to the event log.

4. (Optional) Configure logging file transfers with log4net

log4net can be used to help with logging / notifications on file transfers. All succeeded file transfers are logged as INFO level events and all failures are logged as ERROR level events.

The name of the logger used is provided in the routines task parameter "TransferLoggerName" and the logger can be configured in the FrendsAccService.exe.config file.

Example logger configuration with SmtpAppender for log4net:

<appender name="CobaltSmtpAppender" type="log4net.Appender.SmtpAppender"> 
    <to value="to@domain.com" />
    <from value="from@domain.com" />
    <subject value="Cobalt transfer result" />
    <smtpHost value="SMTPServer.domain.com" />
    <bufferSize value="1" />
    <lossy value="true" />
    <evaluator type="log4net.Core.LevelEvaluator">
        <threshold value="ERROR"/>
    </evaluator>
    <layout type="log4net.Layout.PatternLayout">
        <conversionPattern value="%newline%date [%thread] %-5level %logger [%property{NDC}] - %X{transfername} file: %X{sourcefile} ended with result %X{result} - %message%newline%newline%newline " />
    </layout>
</appender>

<logger name="FileTransferSmtpLog">
    <appender-ref ref="CobaltSmtpAppender" />
    <level value="ERROR" />
</logger>

The following variables can be accessed in the conversionPattern with the %X{variableName}:

Log4net is designed to fail silently if it fails while trying to write to the log appender. This should be taken into account when creating reporting with log4net.


UPGRADING

Upgrading from 1.5 or older versions

Upgrading from 1.5 or older versions requires you to recreate the transfer configuration CP's with the new schema versions as well as use the newer versions of the Cobalt routines.

Upgrading from 1.6

Routines and CPs from 1.6 are compatible with the latest 1.7 version: even though the schemas have been changed, the old schema is still accepted and e.g. the encoding operations are dynamically converted to corresponding message processing steps.

Please note that the Rebex.Net assemblies have been updated from 1.0.2896 to 1.0.3723, and you cannot use the old Rebex versions with the newer Cobalt versions or vice versa - unless you deploy the older Rebex.Net versions first to the Global Assembly Cache (GAC).

Also please note the changed CP schema requires you use Iron 2.4 SR1 or later. On previous Iron versions the existing schemas may not update correctly, and MessageProcessingStep nodes will get duplicated every time you edit the CP. This issue was fixed in 2.4 SP1.

Upgrading from 1.7 beta

The API references were modified since the 1.7 beta, so upgrading to the final 1.7 version requires you to update and recompile possible extensions made against the 1.7 beta. Also, since 1.7 beta used the same old Rebex.net assemblies as 1.6, upgrading to the final 1.7 version means you need to update all workflows using the Rebex assemblies at the same time.

Using multiple Cobalt versions side by side

You may not want to upgrade all existing Cobalt workflows to use the latest workflow, e.g. if you have made extensions that rely on a specific version of Cobalt. To do this, you need to deploy the different Cobalt versions to the Global Assembly Cache (GAC), where they can be loaded to different workflows as needed.

Upgrading Cobalt manually

Because the latest version of Cobalt requires many improvements and fixes to FRENDS Iron, the recommended way to upgrade Cobalt is to upgrade Iron (and Cobalt with it) to the latest version. This way, there should be no compatibility problems or issues with bugs already fixed.

However, if you absolutely cannot update Iron, and accept that you will likely encounter problems, you can update Cobalt manually as follows:

  1. Get the internal Cobalt release zip file with the latest assemblies and schemas and extract the files to a local directory.
  2. Copy the Frends.Cobalt.dll assembly to \Program Files\Frends Technology\FRENDS Iron
  3. Copy also the latest Rebex.*.dll assemblies to \Program Files\Frends Technology\FRENDS. Normally these are updated with Iron, but you can find the latest assemblies also from the zip file, in folder Frends.Cobalt.Extensions\lib
  4. Import the sample Cobalt routine - which also imports the latest schemas - to Iron by importing the routine from the FRENDSCobalt-Routine.xml file.

CONFIGURING A SAMPLE TRANSFER ROUTINE

1. Set up sample folders and files

  1. Create folders for testing:
  2. Give the FRENDS Iron service account read, write and modify access to the C:\Cobalt directory and its subdirectories.
  3. Create a new text file to C:\Cobalt\In with the name Sample.txt. It can be left empty if you wish.

2. Create a connection point

  1. In FRENDS Iron management console navigate to FRENDS / Routine elements / Connection points.
  2. Right click and select "Add new Connection Point".
  3. Name it SampleCP.
  4. Click "Load Schema".
    CP
  5. If there is no existing FRENDS Cobalt schema in the list, or you want to be sure to use the latest version of Cobalt do as follows, otherwise continue from step 6.
    1. Click on the browse (...) button.
    2. Select "Frends_Cobalt_CP.xsd" from the installation folder, default: C:\Program Files\Frends Technology\FRENDS Iron.
  6. Click OK.
  7. Configure source:
    CP Source section
  8. Configure destination:
    CP Destination section
  9. Configure parameters:
    CP Parameters section
  10. Leave the message processing step to use PassThrough type, since we do not want to use any processing.
    CP Message processing section

3. Create a new routine

  1. In FRENDS Iron management console navigate to FRENDS / Routines.
  2. Right click and select "Add new Routine".
  3. Name the routine and select the Cobalt1.7 from the Task drop down menu.
  4. Check the "Use Connection Points" checkbox, select the "Single" radio button and then select SampleCP from the Connection Point drop down menu.
    Routine settings
    Note: This routine is to be started manually for now, so no schedule is needed.
  5. Set up task arguments on the "Task Arguments" tab (see the Cobalt task transfer parameters section for more details on the options):
    Routine task arguments
  6. Click OK.

4. Run the routine

Now the created FRENDS Cobalt transfer is ready to be run from the routines view. Just right click and select "Run Once".

If so desired the routine can be scheduled to be run with the regular FRENDS Iron scheduling tools.


TECHNICAL OVERVIEW

FRENDS Cobalt is implemented as a Windows Workflow Foundation 3.5 workflow that is run in a FRENDS Iron routine. The next section describes the steps in the workflow of a typical file transfer.

Workflow overview

Cobalt workflow

The file transfer workflow is depicted in the diagram above. The overall process goes as follows (the step names correspond to the activity names in the diagram):

  1. Initialize
    Initialize the configuration and open the connection to source endpoint.
  2. GetFiles
    Get a list of files from the source endpoint according to the filename/mask.
  3. Condition - no files to move
    If there are no files matching the filename/mask in the List files step, close the connection to the source endpoint and exit.
  4. OpenDestination
    Once we know there is something to transfer, open the connection to the destination endpoint.
  5. Go through the file list
    For every file in the list returned from the source endpoint, the following process is repeated:
    1. GetFile
      Get a file from the source endpoint to the local work directory.
      If the parameter "RenameSourceFileBeforeTransfer" is set to true (default), the file is first renamed with a temporary filename before transfer.
    2. ExecuteMessageProcessingSteps
      Execute every MessageProcessingStep defined in the configuration. The steps are executed in sequence, in the same order that they are defined in the configuration.
      The steps process local temporary files as follows: the path to the file originally fetched from the source endpoint is given to the first step. The first step returns the path to the file it created as a result of its processing (this may be the same path as given originally to the step if it did not need to change the file or create a new file). This path is then passed to the next step, which again returns a path to its result file, which is given to the next step, and so on.
    3. Execute SourceFileOperation
      Rename or move the source file.
      This is done before transferring the file to the destination, this means that possible errors in the renaming or moving that would cause the transfer to fail will happen as early as possible - before we actually try to transfer files onward.
    4. Put the file to destination endpoint
      If destination file already exists, depending on the parameter "DestinationFileExistsAction" either an exception is thrown, the destination file is overwritten or the source file is appended to the destination file.
      If the parameter "RenameDestinationFileDuringTransfer" is true, the file is first transferred with a temporary file name and afterwards renamed to intended filename, otherwise the file is transferred with the intended filename. The intended filename has its possible file masks expanded.
      Note: When "DestinationFileExistsAction" is set to Error, there is a small chance that the file with the same name will be overwritten. This will only happen if a file with the same name is written by another process after the Cobalt workflow checks for the file's existence.
    5. Delete source file
      Delete the source file if the parameter "SourceOperation" is set to Delete.
  6. Finish
    Close the source and destination endpoint connections.

Error handling

If the opening of the connection to the source endpoint fails, or the listing of the source files fails, the transfer is immediately aborted and an error is logged to the event log.
Note: This error will not be logged to the database.

If the source connection is opened correctly, but the transfer of a single file fails, the workflow will try to continue from the next file until all the files have been processed.
Note: This means there may be many redundant tries to move files if e.g. the user does not have rights to write to the destination. There will be a separate error for each attempt.
On connection errors FTP(S) and SFTP endpoints will try to reopen the connection and retry the failed operation once per operation.

Extending FRENDS Cobalt

While in most cases the core functionality FRENDS Cobalt provides for file transfer is sufficient, you may have cases which require more functionality. If, for example, the file conversion options are not sufficient enough, you could create a custom MessageProcessingStep for handling the required conversion for transferred files. You may also want to use a completely different protocol for transferring files than what are available in FRENDS Cobalt by default. Support for different protocols and other custom endpoint behavior can be achieved by creating a custom endpoint. Information on how to extend FRENDS Cobalt and some samples can be found Extending FRENDS Cobalt.


TRANSFER PARAMETER REFERENCE

There are two places where transfer parameters can be set:

Cobalt task transfer parameters

The Cobalt task takes four parameters: the transfer configuration as XML, and a set of optional technical parameters for the transfer:

ConfigXml

The transfer configuration as XML string. It is recommended the configuration is given as a CP reference, i.e. {CP:/}

WorkDir (optional)

Folder that FRENDS Cobalt uses to store local working copies of files. If empty, the FRENDS Iron service user account's temporary directory is used. Note: If you define the WorkDir, make sure the FRENDS Iron Service user account has read, write and modify access to the directory.

TransferGroupName (optional)

Free-form name describing the transfer. It is shown in error and transfer log reports, and can be used to group many different transfers together in the reports

TransferLoggerName (optional)

Name for the log4net transfer logger, if one is used. For details on this, see section "Configure logging file transfers with log4net"

Transfer specific parameters (CP Schema)

Source

Type

[File | Ftp | Ftps | Sftp | Custom]
The protocol type to use. The type specific configuration is defined in the sections below

Directory

Directory on server where the transferred files are located. You can also use relative paths, in which case the path will be resolved relative to the initial working directory. For FTP/SFTP, this directory is the user's home directory, and relative paths should work OK. However, for File endpoints, it will be \Windows\System32\ by default. As this almost certainly is not correct, you must always use absolute paths for File endpoints.

Note: When using FTP transfer the FTP user must have read, write and modify permissions to source/destination folder. If local directory is used, read, write and modify permissions to the source/destination directory must be assigned to FrendsAccService user.

Macros can be also used for defining the directory. See Macro reference for details on how to use macros.

FileName

Name of the file(s) to be transferred. File masks can also be used here for transferring several files. The file mask uses regular expressions, but for convenience, it has special handling for '*' and '?' wildcards. See the table below for examples.

Mask Matches Does not match
*t.txt text.txt, t.txt foo.txt, text.foo
?t.txt 2t.txt t.txt, tt.foo
test.(txt|xml) test.txt, test.xml test.foo, foo.txt
test.[^t][^x][^t] test.xml, test.foo test.txt, test.tii
test\d{4,4}.txt test1234.txt, test6789.txt test123.txt
<regex>^(?!prof).*_test.txt pro_test.txt, pref_test.txt, _test.txt prof_test.txt, pro_tet.txt

Note: Because regular expressions are used, you need to escape special characters such as parentheses in your filenames with a backslash(\).
E.g. Filename: "customer\(123\)_Q1.xml" to only match the file: customer(123)_Q1.xml.

By default, the regular expressions are compiled as case-insensitive, which means that a regular expression: file\d{6,6}env.dta would match both filenames file123456env.dta and FILE445566ENV.DTA. If you want to use pure regular expressions for matching, like if you want your regular expression to be compiled as case sensitive or you want to avoid the special handlings for '*' and '?' characters you have to use <regex> keyword at the beginning of your regular expression. If, for example, you want to make the previous example to match only the uppercase filenames, you would use a regular expression like: <regex>(?-i)(FILE\d{6,6}ENV.DTA).

Server

Common server parameters for the transfer types that fetch files from a remote server.

Address

Address of the server.

Port

Port number for server.

Username

Username to logon to server. NOTE: File endpoint only supports username for remote shares and needs that the username must be in the format DOMAIN\Username.

Password

Password for user on the server.

Ftp

FTP specific settings

TransportType

[Ascii | Binary]

  • Ascii mode sends files via FTP as 'text' and should *only* be used for transferring ASCII text files.
  • Binary modes send files via FTP as raw data and should be used for transferring non-text files. (default)
Mode

[Passive | Active]
FTP connection mode.

Sftp

SFTP specific settings

LoginType

[Username-Password | Username-PrivateKey | Username-Password-PrivateKey]

  • Username-Password = the user name and password given in the Server section is used for authentication
  • Username-PrivateKey = the user name (given in the Server section) and the private key file (given in this section) are used for authentication.
  • Username-Password-PrivateKey = the user name and password as well as the private key is used for authentication. This may not be very commonly supported. GlobalScape SFTP server for example does support it, but use it at your own risk.
PrivateKeyFileName

Location of private key file to be used for authentication if public key authentication is used on the server.

PrivateKeyFilePassword

Password for private key file.

ServerFingerPrint

Fingerprint for SFTP server. When using Username-Password authentication it is recommended to use server fingerprint in order to be sure of the server you are connecting.

Ftps

FTPS specific settings

TransportType

[Ascii | Binary]

  • Ascii mode sends files via FTP as 'text' and should *only* be used for transferring ASCII text files.
  • Binary modes send files via FTP as raw data and should be used for transferring non-text files. (default)
Mode

[Passive | Active]
FTP connection mode.

SecureDataChannel

[true | false]
Is protection of transferred data required.

SslMode

[Explicit | Implicit]

  • Explicit = a separate request is made for establishing secure connection. Default FTP port is used for secure connection.
  • Implicit = secure connection is established as soon as the connection to a server is made, but a different port (990) is used for implicit security.
EnableClientAuth

[true | false]
If client authentication is enabled both client and server are authenticated. The client certificate is searched from user's certificate store.

ServerName

Required if client authentication is enabled. The ServerName must be exactly the same as in server certificate.

Timeout for FTP operations is 60 seconds. This means that data transfer is timed out after 60 seconds of inactivity and not from the start of the transfer.

Custom

You can provide your own custom endpoint implementation as a compiled assembly, and pass initialization parameters to it via this section. For more details on how to do this, see the Extending FRENDS Cobalt guide.

NOTE: The implementation must extend the EndPointBase base class, and provide the necessary constructors in order to work.

AssemblyName

Assembly name where the custom class resides in, e.g. Frends.Cobalt.Extensions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null

ClassName

Class name of custom class, e.g. Frends.Cobalt.Extensions.FileLogger

Parameters

Custom parameter string to be passed as is to the custom implementation constructor. This parameter can be e.g. a connection string or any other custom parameters

Destination

Destination parameter section contains same parameters as in Source section, so same descriptions generally apply to them too with exception in FileName parameter.

FileName

File name or file mask for the remote file. '?' characters are not allowed in file mask. If no file name is given the original file name is used for destination file name.

Examples of usage:

Macros can also be used for destination file names. See Macro reference for details on how to use macros.

Parameters

General parameters for the transfer

RenameSourceFileBeforeTransfer

[true | false]
Should the source file be renamed with a temporary file name before transferring the file. This is a way to prevent other users to access the file with its original name while transfer is in progress. Set this to false if the used source endpoint implementation doesn't support source file renaming. Default value is true.

The temporary file name is created using the following scheme: cobalt_[current time in ticks][random 8 character file name].8CO
For example: cobalt_634509139954167644lomy3uzg.8CO

RenameDestinationFileDuringTransfer

[true | false]
Should the file be transferred to destination endpoint with a temporary file name and rename it after the transfer is completed. This is a way to prevent other users to access the file at the destination endpoint with its actual name before the transfer is completed. Set this to false if the used destination endpoint implementation doesn't support file renaming. Default value is true.

The temporary file name is created using the same scheme as for the source file: cobalt_[current time in ticks][random 8 character file name].8CO

DestinationFileExistsAction

[Append | Overwrite | Error]
What to do if destination file exists. By default throws an error.

NoSourceAction

[Error | Info | Ignore]
What to do if the source file is not found. By default throws an error.

NOTE: This error is not logged by log4net transfer logger, neither is it written in the file transfer log database

SourceOperation

What to do to the source file after a successful transfer

Operation

[Delete | Rename | Move | Nothing]
Defines the operation to perform to source file(s) after successful transfer. By default deletes the file from the source directory.

  • Delete = Delete the source file(s).(default)
  • Rename = Renames the source file(s) to use the given name. The name (given in the To parameter) can use file macros (and file masks, although they are not recommended). From 1.6 onwards, you can also move the renamed files to another directory, by giving a directory path.
    Note: This may overwrite files.
  • Move = Moves the source file(s) to different directory (given in the To parameter) using the original file names.
    Note: This may overwrite files.
  • Nothing = Do nothing, leaves the file to the source directory.
To

The path to move or to rename the files to.

  • For Rename, you can use file macros and also specify a directory where to move the files to, e.g. /subdir/%Date%file.txt. If you don't define a directory path, the source directory is used. When using rename, the To-parameter must always contain a file name.
    Note: The possible directory must exist before the transfer is executed, because it is not created automatically.
  • For Move, you must give a directory name. You cannot use file macros, or define file names in the parameter.
    Note: The possible directory must exist before the transfer is executed, because it is not created automatically.

Message processing steps

You can define steps for processing messages after they have been fetched from the source endpoint but before they are sent to the destination endpoint.

The default Cobalt CP schema has three steps you can use. However, you can have as many steps you like, if you just create a custom CP schema.

Type

[PassThrough | Xslt | Encoding | Custom]
The message processing step type. By default PassThrough.

LocalBackup

Parameters for the backup step that takes a local backup of the transferred files.

BackupDirectory

Root directory for the backups. Must be an absolute local path or network share, like "E:\Backup\" or "\\store\backup".
For each transfer, a new backup directory named after the file transfer start time and the batch ID is created underneath the root directory. Copies of all files transferred in the single transfer will be put to this transfer specific directory.

Cleanup/DaysOlder

Number of days to keep the backups. Backup subdirectories older than this are deleted. Dates are compared by the last write time of the directory.

Cleanup/Enabled

[true|false]
Whether or not the automatic cleanup is enabled. If false (default), the files will not be cleaned up by the step. Note that if the automatic cleanup is disabled, you must clean up the files in some other way.

Xslt

XSLT processing step parameters

XslFileLocation

Absolute path to the XSL transformation file

Encoding

Encoding step parameters

SourceEncoding

Source file character encoding from which to convert.

DestinationEncoding

Destination file character encoding to which to convert.

Custom

You can provide your own custom message processing step implementation as a compiled assembly, and pass initialization parameters to it via this section. For more details on how to do this, see the Extending FRENDS Cobalt guide.

AssemblyName

Assembly name where the custom message processing step implementation class resides in, e.g. Frends.Cobalt.Extensions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null

ClassName

Class name of custom class, e.g. Frends.Cobalt.Extensions.FileLogger
NOTE: The implementation must extend the MessageProcessingStepBase base class, and provide the necessary constructors in order to work.

Parameters

Custom parameter string to be passed as is to the custom implementation constructor. This parameter can be e.g. a connection string or any other custom parameters

Other parameters

TransferName

Can be used to give a descriptive name to a single transfer.

Macro reference

Macros can be used to dynamically configure source directory, destination directory or destination file name for a file transfer.

Generally the following rules apply for macros:

The following macros can be used with all of dynamically configurable locations for file transfer:

Destination file name has two additional macros that can be used for dynamically creating destination file name.

Note:With destination file name it is recommended to only use file macros, since in future the usage of file masks for such purpose will be deprecated. Especially, if you want to add a time stamp to a transferred file name, you can only do this with file macros.

Below are some examples with imaginary sample.txt file:

Not recommended:

Recommended:


Known issues

PersistenceException blocks stopping FRENDS Iron service when Cobalt transfer is running

If the Cobalt workflow is running when the FRENDS Iron service is being stopped, the workflow runtime tries to pause and persist its state to the WorkflowStore database. Unfortunately, due to the way the Cobalt workflow is structured, it cannot be serialized and therefore persisted. This causes the System.Workflow.Runtime.Hosting.PersistenceException to be thrown, which also blocks stopping the workflow runtime and the FRENDS Iron service. On the other hand, the Cobalt transfer would not be able to resume the transfer anyways, so it is good to allow the transfer to finish.

Therefore, you should wait until all current Cobalt transfers have been completed before stopping the FRENDS Iron service.

Source file operation may overwrite existing files on FTP

When renaming or moving source the source files with SourceOperation with FTP, you should note that existing files may get overwritten. At least Microsoft's IIS FTP Server overwrites existing files renaming/moving files, this may happen on other servers as well.

If you want to store the original source files somewhere, and do not want to use the backup operation, it is recommended to append e.g. the datetime to the moved or renamed file name by using a file name like %DateTime%*

Failure in source file operation logs the transfer failed even if the files were transferred

SourceFileOperations Delete or Nothing are executed only after the actual file transfer has been completed. There is a possibility that they will fail (e.g. another file with the original source file name has been created in the directory, so renaming the temporary file back to the original name (option Nothing) will fail). This error will be logged as a failed file transfer, even though the file has been transferred to the destination. In this case, the logged error description will mention that only the source operation has failed and the file has been transferred.

If you get these kinds of errors, you should fix the original error, e.g. not writing a new file to the source directory with always the same name

Failures with fetching source files are not logged to transfer log

The transfer log only logs individual file transfers that have succeeded or failed. If fetching the source files fails, e.g. because the server cannot be accessed, or there are no files and the SourceFileNotFoundAction is set to Error, the transfer will fail, but nothing will be logged to the transfer log.

This issue will be fixed in future versions of FRENDS Cobalt.

Cobalt 1.7 custom message processing steps or custom endpoints don't work with Cobalt 1.8

While Cobalt 1.8 is technically backwards compatible with Cobalt 1.7, message processing steps or custom endpoints built against Cobalt 1.7 cannot be used by Cobalt 1.8, because the Cobalt reference is strong-named.

There are three ways to fix or work around this issue: