Difference between revisions of "OS4X Core event scripts"

From OS4X
Jump to navigation Jump to search
Line 25: Line 25:
  
 
== start receive script ==
 
== start receive script ==
Will be started at the beginning of an OFTP file transfer from partner to local site after handshaking SFIDs.  
+
Will be started at the beginning of an OFTP file transfer from partner to local site after handshaking SFIDs.
 +
'''This script is the only event script which will be started INSIDE the OFTP protocol state machine in order to let a file be received or not!''' For this feature, the returncode of the event script is used to decline the receipt of a file and to create an SFNA error message (if returncode of script is not equal to zero) or to accept the file, producing an SFPA message.
  
 
Parameters:  
 
Parameters:  
Line 36: Line 37:
 
*7. SFID destination  
 
*7. SFID destination  
 
*8. SFID originator  
 
*8. SFID originator  
*9. [optional: OFTPv2 file description]  
+
*9. [optional: OFTPv2 file description]
 +
 
 +
Possible return values are interpreted as shown below:
 +
 
 +
OFTP 1.x session:
 +
*1: Invalid filename.
 +
*2: Invalid destination.
 +
*3: Invalid origin.
 +
*4: Storage record format not supported.
 +
*5: Maximum record length not supported.
 +
*6: File size is too big.
 +
*10: Invalid record count.
 +
*11: Invalid byte count.
 +
*12: Access method failure.
 +
*13: Duplicate file.
 +
*99: Unspecified reason.
 +
 
 +
In addition, in OFTP2 session:
 +
*14: File direction refused.
 +
*15: Cipher suite not supported.
 +
*16: Encrypted file not allowed.
 +
*17: Unencrypted file not allowed.
 +
*18: Compression not allowed.
 +
*19: Signed file not allowed.
 +
*20: Unsigned file not allowed.
 +
 
 +
This feature was first introduced in build 2007-10-16 of OS4X.
  
 
== end receive script ==
 
== end receive script ==

Revision as of 19:53, 16 October 2007

The scripting interface gives you the possibility to start processes during an OFTP connection like managing an EDM system, sending confirmation eMails, deleting files, etc. The scripts have all information available as parameters at this point of time the script will be started.

The scripts are defined via web interface. This configuration is stored in the database, which will be read by every binary on startup and on every configuration reload. If a script is unavailable or not runnable (i.e. execute permissions are missing, user has no read permissions etc.), the script will not be started.

The following virtual filenames are reserved and therefor no "normal" script will be run on these files (send, receive, xERP & block):

  • ODETTE_CERTIFICATE_REQUEST: OFTP2 automatic certificate exchange request
  • ODETTE_CERTIFICATE_DELIVER: OFTP2 automatic certificate exchange delivery
  • ODETTE_CRL_REQUEST: OFTP2 automatic certificate revocation list request
  • ODETTE_CRL_DELIVER: OFTP2 automatic certificate revocation list delivery
  • OS4X_UPDATE: OS4X update package

start session script

Will be started at the beginning of an OFTP session after handshaking SSIDs and passwords.

Parameters:

  • 1. partner shortname
  • 2. partner index value

end session script

Will be started at the end of an OFTP session after receiving an ESID („end session ID“).

Parameters:

  • 1. partner shortname
  • 2. partner index value

start receive script

Will be started at the beginning of an OFTP file transfer from partner to local site after handshaking SFIDs. This script is the only event script which will be started INSIDE the OFTP protocol state machine in order to let a file be received or not! For this feature, the returncode of the event script is used to decline the receipt of a file and to create an SFNA error message (if returncode of script is not equal to zero) or to accept the file, producing an SFPA message.

Parameters:

  • 1. partner shortname
  • 2. virtual filename
  • 3. absolute filename of received file AFTER successful transfer
  • 4. absolute filename of receiving file DURING transfer (temporary)
  • 5. filesize in kilobytes (kB) given by partner (may not be true size)
  • 6. partner index value
  • 7. SFID destination
  • 8. SFID originator
  • 9. [optional: OFTPv2 file description]

Possible return values are interpreted as shown below:

OFTP 1.x session:

  • 1: Invalid filename.
  • 2: Invalid destination.
  • 3: Invalid origin.
  • 4: Storage record format not supported.
  • 5: Maximum record length not supported.
  • 6: File size is too big.
  • 10: Invalid record count.
  • 11: Invalid byte count.
  • 12: Access method failure.
  • 13: Duplicate file.
  • 99: Unspecified reason.

In addition, in OFTP2 session:

  • 14: File direction refused.
  • 15: Cipher suite not supported.
  • 16: Encrypted file not allowed.
  • 17: Unencrypted file not allowed.
  • 18: Compression not allowed.
  • 19: Signed file not allowed.
  • 20: Unsigned file not allowed.

This feature was first introduced in build 2007-10-16 of OS4X.

end receive script

Will be started after an OFTP file transfer from partner to local site after handshaking EFIDs („end file ID“)

Parameters:

  • 1. partner shortname
  • 2. virtual filename
  • 3. absolute filename of received file AFTER successful transfer
  • 4. error indicator: 0 means no error, any other displays an error
  • 5. partner index
  • 6. SFID destination
  • 7. SFID originator
  • 8. [optional: OFTPv2 file description]
  • 9. data throughput in kB/sec

start send script

Will be started at the beginning of an OFTP file transfer from local site to partner after handshaking SFIDs.

Parameters:

  • 1. partner shortname
  • 2. virtual filename
  • 3. real filename with absolute path
  • 4. send queue entry comment
  • 5. partner index

end send script

Will be started at the end of an OFTP file transfer from local site to partner after handshaking SFIDs.

Parameters:

  • 1. partner shortname
  • 2. virtual filename
  • 3. real filename with absolute path
  • 4. send queue entry comment
  • 5. error indicator: 0 means no error, any other displays an error
  • 6. partner index
  • 7. data throughput in kB/sec

xERP script

Will be started whenever an EERP is receiver from a partner. Useful for later-on system-internal cleanup processes. Parameters:

  • 1. partner shortname
  • 2. virtual filename
  • 3. real filename
  • 4. comment
  • 5. error flag: 0=no error, otherwise NERP error code
  • 6. partner index

blocked script

Will be started if a send queue entry will be blocked. If more than one entry will be blocked (i.e. if a connection problem occurs), the script will be executed for every send queue entry seperately.

Parameters:

  • 1. partner shortname
  • 2. virtual filename
  • 3. real filename with absolute path
  • 4. send queue entry comment
  • 5. partner index

debug daemon log script

Every time a debug log will be dumped, this script will be started.

Parameters:

  • 1: absolute path to the logfile

license high water mark script

Each time the license is checked and a configurable high water mark has been exceeded, this script will be started. This script could be used i.e. for sending an administrator an email with license information or for changing the status of the OFTP system in an system management tool.

Parameters:

  • 1: configured high water mark in percent
  • 2: actual amount of configured partners
  • 3: licensed amount of configured partners

OS4X automatic software update script

If enabled in the configuration via Enable automatic update mechanism & OS4X automatic software update script, this script or program is executed each time a file with the virtual filename "OS4X_UPDATE" is successfully received.

Parameters:

  • -f <absolute filename of received file>

automatic certificate import script

If an automatic certificate exchange import succeeds, this script will be called.

Parameters:

  • 1. partner shortname
  • 2. partner index value