System

The System page allows you to clean up unwanted log and temporary files, set targets and configure formats such as date and time.

Figure 1.1. System

System

Unused Files

Allows you to set the duration after which unused temporary and log files are automatically deleted.

The default duration is set to 7 days.

You can also elect to clean up the temporary and log files immediately, by clicking Clean temporary files now and Clean log files now.

Unused Sessions

Allows you to set the duration after which unused sessions are automatically deleted.

The default duration is set to 24 hours.

You can also elect to clean up the unused sessions immediately, by clicking Clean sessions now.

Targets

After a job finishes, a target may pick up the result. Different targets may be chained for further processing. Target processing is also a task run by the Job Engine.

Target Constants

If you find yourself typing a string repetitively when configuring targets, you can define that string as a constant. Then you can refer to that constant in target property values like ${constant-name}. Target constants can be enabled/disabled. Only enabled constants can be used in target configurations. You can define multiple constants with the same name, but only one of them can be enabled at any time.

Target List

  • Target Creation/Update/Deletion

    All manipulations can be done in the Target Wizard. For most of the targets, configuration is simple. You need to provide a name, enable the target and provide values for required target properties.

  • Status

    Targets can also be enabled/disabled. Only enabled targets can be used in RenderReport task. You can define multiple targets with the same name, but only one of them can be enabled. If you make one target enabled, the rest of the targets with the same name will be disabled automatically.

    Targets can be be available/unavailable to anonymous users. When the Available to anonymous users check box is selected, the target is accessible in anonymous mode. By default, only the "browser" target is available.

  • Target Properties and Parameters

    A target requires certain properties such as file name, folder name, port number and so on.

    When editing a target, the Target Wizard lists all required properties for the target. An administrator has several options when configuring those property values:

    • Provision of an exact string value for some properties.
    • Reference to target constants.
    • Definition of parameters in some properties if they should be provided by end users. For example, the parameter in property "filename" can be defined as "${file#report}_${date}". End users should provide values for those parameters when invoking targets.

  • Output Types for Report Rendering

    A target provides various output types such as CSV, HTML, PDF, Microsoft formats and so on.

    After the properties are set, the Target Wizard enables you to choose among different output types for report rendering purpose. You can choose multiple types at a time for convenience. You can also print the report directly.

    Table 1.1. Output Types for Report Rendering

    CSVGlint
    HTMLLine Printer
    Logical RMLLogical RML Tree
    Microsoft DOCXMicrosoft Excel
    Microsoft PPTXODF Spreadsheet
    PCLPDF
    PostscriptPrint
    Rich Text FormatSimple HTML
    XMLZipped Bitmap
    Zipped JpegZipped Png
    Zipped SvgZipped Tiff
    Zipped Wbmp 

Create New Target

When you create a new target using the Target Wizard, you should fill in values, for example parameters, into the property fields. Nested parameters are not supported. For example, you cannot specify a parameter like ${file##${reportname}}.

JDBC Target

A JDBC Target allows reports to be written directly into a database. This is useful if you have some subsequent program to pick them up or otherwise act on them - for example a document management system. Each report is written as a record into a specific table in the database. The report data itself is stored as a BLOB. Before you can use the JDBC target, you need to set up a database with a table that has the correct schema to accept a report file. An example as shown:

CREATE TABLE JOBOUTPUT (
  id INTEGER NOT NULL GENERATED ALWAYS AS 
  	IDENTITY (START WITH 1, INCREMENT BY 1),
  name VARCHAR(256) NOT NULL,
  lastModified BIGINT NOT NULL,
  content BLOB NOT NULL,
  CONSTRAINT JOBOUTPUT_PK PRIMARY KEY(id) ) 

Once the database is setup, configuration will write into a table called JobOutput in the Derby database that is built into the Elixir Repertoire Server:

Table 1.2. JDBC Target Configurations

NameValue
Driverorg.apache.derby.jdbc.EmbeddedDriver
URLjdbc:derby:/home/.../jdbctarget
Table${update table##JobOutput}
User${userid##Enter your userid}
Password${password##Enter your password}
Filename${filename##Job_Output_Report}
Overwritetrue

JMS Target

A JMS Target can be used for asynchronous messaging. JMS applications can use job messages as a form of managed request/response processing, to give remote feedback to the users on the outcome of their send operations and the fate of their messages. Examples of job messages are Exception, Expiration, Confirm on arrival (COA), Confirm on delivery (COD), etc.

Table 1.3. JMS Target Configurations

NameValue
DestinationRQueue
User${userid##Enter your userid}
Password${password##Enter your password}
Filename${filename##Pet_Store_User_Accounts_Report}
Reply requiredtrue
Timeout${reply timeout in secs##30}
Reply success keyword${reply success keyword##OK}
Reply success pattern${reply success pattern##^.*OK.*$}

Mail Target

A Mail Target allows the output to be sent by email. There are a number of parameters to specify, but remember that you can use substitutions to avoid hard-coding those that you decide need to be flexible. The report will be sent as an attachment by email, so you can choose the render format you prefer.

Table 1.4. Mail Target Configurations

NameValue
To${to##sam@elixirtech.com}
SMTP hostelixir.aspirin
From${from##susan@elixirtech.com}
Cc${cc##bob@elixirtech.com}
Subject${subject##Pet Store User Accounts Report From Elixir Server}
Message${message##Your report is attached.}
Filename${filename##Pet_Store_User_Accounts_Report}

PDF Signer Target

PDF Signer Target is used when a PDF output needs to be signed digitally. It prints a "signature" in a PDF file when the file is rendered.

Table 1.5. PDF Signer Target Configuration

NameValue
Keystore${key.url##C:/Java/jre7/bin}
Keystore type${keystore-type}
Store encrypted passwordfalse
Store password${key-password##keyStorePassword}
Key alias${key-alias}
Signer appearance${signer-appearance##self-signed}
Info reason${info-reason##Reason for signature}
Info location${info-location##bottom-left}
Sign width${sign-width##100}
Sign height${sign-height##60}
Sign pagesign-last-page
Sign image${signature-image-url##D:/image/logo.png}
Certification level${certificate-level##certificate-no-changes}
FilenameSpecify file name here

PDF Signer Target Properties

Signer appearance

There are two types of signing mode. They are self-sign and wincer-sign.

self-sign signer can be generated using Java key generator (keytool.exe). An example of a signature command is as follows :

keytool -genkey -keyalg RSA -alias QAkey -keypass 
mypassword  
	 -keystore keystore.ks -dname "cn=My Key Name, c=SG"

wincer-sign is recommended if higher security is required. Certificate obtained is installed to the web browser and needs to be exported to be used in PDF signing.

Keystore type

For self-sign, no keystore type is required. For wincer-sign, the keystore type will depend on the respective vendor. For example, a VeriSign keystore type will be pks12.

Keystore

The directory of the keystore is entered here. repository is prohibited for this parameter.

Key alias

This parameter is optional. It is to define the alias used by the keystore file.

Store password

key-password is the password entered when creating the keystore file. The password can either be in encrypted or unencrypted form.

Store encrypted password

This parameter holds a boolean value, true if the key password is encrypted and false if otherwise.

Sign page

This parameter is to specify the page that the signature is placed. sign-no-page will mean that the signature will not be visible. sign-first-page and sign-last-page implies that the signature will be placed on the first and last page of the PDF file respectively. If you wish to place the signature on a specific page, enter the page number as the value for the parameter. For example, ${sign-page##5}, for placing the signature on the 5th page of the PDF document.

Sign width and Sign height

These two parameters are for user to specify the height and width of the signature rectangle size.

Sign image

The directory of the image that is to be used with the signature. When no value is entered for this parameter, there will still be a PDF Signature (self-signed) automatically generated.

Info reason and Info location

The reason for placing a signature in the PDF document and the position of the reason.

Certification level

certificate-not
has no visible signature in the PDF document. The document is digitally counter signed.
certificate-no-changes
displays the signature in the PDF document and no changes can be made to the document.
certificate-form-filling
also displays the signature in the PDF document, but only the filling in of forms, signing and page adding is allowed for the document.
certificate-form-filling-annotation
displays the signature in the PDF document, but only commenting, form fill-in, signing and page adding is allowed.

Print Target

A Print Target allows you to send a report to a named printer. The only option is the name of the printer. If you have multiple alternate printers, you could use a separate target for each printer so that you could control access by different groups. In most cases, the printer names will be fixed and not include substitutions. You can also leave the printer name blank as it will route automatically to the default printer defined on the server.

Table 1.6. Print Target Configurations

NameValue
Printer nameCanon iR C3220 PCL5c

Repository Target

A Repository Target writes the report to the filesystems. You can identify a target folder in the repository and provided it is writable, files will be written there. This works regardless of whether the target filesystem is of type local, secure or dbfs. You should use Repository Targets when you want to allow users to view the reports through their browser as the repository will automatically update to show the latest files.

During the configuration, the "folder" property must refer the "dir##" parameter to an existing target filesystem in the repository. The "folder##" parameter need not as it will create a new folder after its name if it is not found in the repository.

Table 1.7. Repository Target Configurations

NameValue
Folder${dir##ElixirSamples}/${folder##repository}
Filename${filename##Pet_Store_User_Accounts_Report}
Overwritetrue

S3 Target

A S3 Target allows the report to be transferred to a user's Amazon S3 bucket. The available parameters are bucket name, access key, secret key, the folder name in which to transfer, the expiry time of the file (if any), the filename to name the transferred file and the presigned URL protocol.

Table 1.8. S3 Target Configurations

NameValue
Available to Anonymous UsersIf enabled, anonymous users can access the file. Else, only those users who have logged into S3 can access the file.
BucketThe name of the S3 bucket in which the file is to be stored.
Access KeyEnter your Amazon access key.
Secret KeyEnter your Amazon secret key.
FolderThe folder in which to store the file.
ExpiryThe number of days after which the file cannot be accessed anymore.
Filename${filename##Pet_Store_User_Accounts_Report}
Presigned URL Protocol A signed URL is a URL which is valid for a specific time period. Its purpose is to share the pages that have time sensitive information, or when you want to share a file with specific people alone. Such information becomes invalid once the specified time period has passed.

SFTP Target

A SFTP Target allows the report to be transferred to a user's secured FTP Server. The available parameters are user, password, host, port, dir and filename. The port is optional and will default to 22, which is the default SFTP port, if not specified.

The parameter in "dir" property must be an existing directory found in the target ftp server.

Table 1.9. SFTP Target Configurations

NameValue
Host${sftp host##domain_name.com}
Port${port##22}
Directory${dir##dept1}/${folder##Pet_Store}
Filename${filename##Pet_Store_User_Accounts_Report}
User${userid##Enter userid to access sftp client}
Password${password##Enter password to access sftp client}

Socket Target

A Socket Target sends the report to a program which is listening, typically on another machine. For example, a program can be written that listens on a company.com port 6000 and writes any data it receives to a database, or to a fax etc. It is up to the receiving program what it does with the data. The server opens a connection to the listening program, using the host and port information required by the socket target and streams the data across the network to the listening socket.

Table 1.10. Socket Target Configurations

NameValue
Hostcompany.com
Port6000

Unzip Target

This target enables you to specify a file name for unzipping purpose. You can enable/disable this target, and set this target available/unavailable to anonymous users.

User Home Target

A Repository User Home Target writes the report to the invoking user's folder in the repository. Users can share jobs and they can keep separate output without overwriting one another. In the example, once the user "Jon" signs in to the repository and runs the job, the report will be written to /User/Jon/Pet_Store.

Table 1.11. Repository User Home Target Configurations

NameValue
Folder${folder##Pet_Store}
Filename${filename##Pet_Store_User_Accounts_Report}
Overwritetrue