The System page allows you to clean up unwanted log and temporary files, set targets and configure formats such as date and time.
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.
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.
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.
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.
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.
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.
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:
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.
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}}.
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
Name | Value |
---|---|
Driver | org.apache.derby.jdbc.EmbeddedDriver |
URL | jdbc:derby:/home/.../jdbctarget |
Table | ${update table##JobOutput} |
User | ${userid##Enter your userid} |
Password | ${password##Enter your password} |
Filename | ${filename##Job_Output_Report} |
Overwrite | true |
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
Name | Value |
---|---|
Destination | RQueue |
User | ${userid##Enter your userid} |
Password | ${password##Enter your password} |
Filename | ${filename##Pet_Store_User_Accounts_Report} |
Reply required | true |
Timeout | ${reply timeout in secs##30} |
Reply success keyword | ${reply success keyword##OK} |
Reply success pattern | ${reply success pattern##^.*OK.*$} |
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
Name | Value |
---|---|
To | ${to##sam@elixirtech.com} |
SMTP host | elixir.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 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
Name | Value |
---|---|
Keystore | ${key.url##C:/Java/jre7/bin} |
Keystore type | ${keystore-type} |
Store encrypted password | false |
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 page | sign-last-page |
Sign image | ${signature-image-url##D:/image/logo.png} |
Certification level | ${certificate-level##certificate-no-changes} |
Filename | Specify file name here |
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
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.
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
Name | Value |
---|---|
Folder | ${dir##ElixirSamples}/${folder##repository} |
Filename | ${filename##Pet_Store_User_Accounts_Report} |
Overwrite | true |
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
Name | Value |
---|---|
Available to Anonymous Users | If enabled, anonymous users can access the file. Else, only those users who have logged into S3 can access the file. |
Bucket | The name of the S3 bucket in which the file is to be stored. |
Access Key | Enter your Amazon access key. |
Secret Key | Enter your Amazon secret key. |
Folder | The folder in which to store the file. |
Expiry | The 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. |
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
Name | Value |
---|---|
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} |
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.
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.
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
Name | Value |
---|---|
Folder | ${folder##Pet_Store} |
Filename | ${filename##Pet_Store_User_Accounts_Report} |
Overwrite | true |