Difference between revisions of "OS4X client-side plugin philosophy"

From OS4X
Jump to navigation Jump to search
(15 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
== Abstract ==
 
== Abstract ==
With the local processing ability of OS4X Webaccess, you can do the following:
+
<u>'''100% pure Java-free!'''</u>
 +
 
 +
 
 +
With the local processing ability of OS4X Webaccess, you can do the following client-side:
 
*dynamically retrieve locally available environments
 
*dynamically retrieve locally available environments
 
*list a structured hierarchy of directory with aliases within a selected environment, sourcing them locally in the context of the logged in user in the client machine
 
*list a structured hierarchy of directory with aliases within a selected environment, sourcing them locally in the context of the logged in user in the client machine
Line 16: Line 19:
  
 
All scripts/programs for every situation can be located on a defined web position (http(s) URL) or available at a local or remote path.
 
All scripts/programs for every situation can be located on a defined web position (http(s) URL) or available at a local or remote path.
 +
 +
 +
File selection via this solution is available with a button in the "new send job" view:
 +
 +
[[Image:NewJobFileSelection DLName.png]]
 +
 +
Receiving jobs to available DLNames is possible via a dynamic DLName selection:
 +
 +
[[Image:FetchJobFileSelection DLName.png]]
  
 
== Requirements ==
 
== Requirements ==
 
For this functionality, you need:
 
For this functionality, you need:
 
*OS4X Webaccess Webbrowser plugin version 1.4.0 and up
 
*OS4X Webaccess Webbrowser plugin version 1.4.0 and up
*Configured environemnt for local processing
+
*Configured environment for local processing
 
**All commands must be configured for the used environment in the used operating system
 
**All commands must be configured for the used environment in the used operating system
  
Line 40: Line 52:
 
=== Supported script locations ===
 
=== Supported script locations ===
 
There are two modes for script locations:
 
There are two modes for script locations:
*web locations: starting with "<code>http</code>", these locations will trigger a special logic by downloading them to the client in case of execution.
+
*Web locations: starting with "<code>http</code>", these locations will trigger a special logic by downloading them to the client in case of execution. The download location is a temporary location, whatever the operating system offers as a temporary path (may be influenced by user settings).
*local location: all configurations which don't start with "<code>http</code>" will start the configured script at the configured position. These must be locally available paths.
+
*Local location: all configurations which don't start with "<code>http</code>" will start the configured script at the configured position. These must be locally available paths.
  
 
In case of a web location, the client checks if the location is approved by the user. For non-approved locations, the user will be prompted for the first time of access to the URL if he allows to download and execute the program/script from the given position.
 
In case of a web location, the client checks if the location is approved by the user. For non-approved locations, the user will be prompted for the first time of access to the URL if he allows to download and execute the program/script from the given position.
  
 
=== Special files ===
 
=== Special files ===
In Windows, script types with the file extension "<code>.vbs</code>" will lead to an invocation of the Visual Basic interpreter in command line mode, which suppresses the opening of command shell windows ("<code>cmd.exe</code>") during execution.
+
In Windows, script types with the file extension "<code>.vbs</code>" will lead to an invocation of the Visual Basic interpreter in command line mode, which suppresses the opening of annoying command shell windows ("<code>cmd.exe</code>") during execution.
  
 
== Script / Programs ==
 
== Script / Programs ==
Line 53: Line 65:
 
*DLName listing script: tool to deliver a list of directories, given in a special format also known as "DLName"
 
*DLName listing script: tool to deliver a list of directories, given in a special format also known as "DLName"
 
*Export script: tool to export selected files in the used environment
 
*Export script: tool to export selected files in the used environment
 +
 +
=== Windows scripting hints ===
 +
When dealing with the pipe symbol "<code>|</code>" scripting could be sometimes tricky. Be sure to escape the pipe for output in scripts. Example:
 +
@echo off
 +
echo dc_r1^|Daimler AG
 +
echo pag^|Porsche AG
 +
echo bmw^|BMW AG
 +
  
 
=== Environment listing script ===
 
=== Environment listing script ===
The environment list script will be executed dynamically on the client to list all available enviromment:
+
The environment list script will be executed dynamically on the client to list all available environment:
  
 
[[Image:StreamingSmoke envList.png]]
 
[[Image:StreamingSmoke envList.png]]
Line 67: Line 87:
 
Output (written to standard output ["<code>stdout</code>"]) must have the following line syntax:
 
Output (written to standard output ["<code>stdout</code>"]) must have the following line syntax:
 
  <internal ID>|<Descriptor for GUI>
 
  <internal ID>|<Descriptor for GUI>
Lines may be seperated by linefeed or carriage-return/linefeed. The internal ID will be re-used later. The separator is the "pipe" symbol.
+
Lines may be seperated by linefeed or carriage-return/linefeed. The internal ID will be re-used later. The separator is the "pipe" symbol "<code>|</code>".
  
 
Example output:
 
Example output:
Line 75: Line 95:
  
 
=== DLName listing script ===
 
=== DLName listing script ===
The DLName listing script will be executed after selection of the enviroment in order to show all available directories/DLNames. All DLNames must be written to standard output, the output expected there will be used for the DLName list.
+
The DLName listing script will be executed after selection of the environment in order to show all available directories/DLNames. All DLNames must be written to standard output, the output expected there will be used for the DLName list.
  
 
[[Image:StreamingSmoke dlnames.png]]
 
[[Image:StreamingSmoke dlnames.png]]
Line 124: Line 144:
 
  D:\catiaV5\s1\env\mx\00000000\testfile5
 
  D:\catiaV5\s1\env\mx\00000000\testfile5
  
Depending on the client's operating system, the input list contains windows or unix paths.
+
Depending on the client's operating system, the input list contains windows or unix paths. Windows path information may include slashes ("<code>/</code>") instead of backslashes ("<code>\</code>") as directory separator.
  
 
==== Format of output file ====
 
==== Format of output file ====
Line 138: Line 158:
 
*Mac OS X:
 
*Mac OS X:
 
  $HOME/Library/Application Support/OS4X/logs/StreamingSmokePlugin.log
 
  $HOME/Library/Application Support/OS4X/logs/StreamingSmokePlugin.log
 +
 +
 +
[[Category:OS4X Enterprise]]

Revision as of 13:26, 8 August 2017

Abstract

100% pure Java-free!


With the local processing ability of OS4X Webaccess, you can do the following client-side:

  • dynamically retrieve locally available environments
  • list a structured hierarchy of directory with aliases within a selected environment, sourcing them locally in the context of the logged in user in the client machine
  • list content of the selected directory, offerung filtering and file type selection
  • export selected (single or multiple) files with a configured program or script
  • grab the created files, upload it to an outgoing send job, keeping the log output for every file for possibly later processing

From end-user's view, the selection works as follows:

  1. Select environment (last selected environment is saved and pre-selected in future calls)
  2. Search and select DLName
  3. Search and select file(s) for export
  4. Start export process

In case of success, the output file(s) will be added to the send job, in case of error an error message shows the output of the process.

All scripts/programs for every situation can be located on a defined web position (http(s) URL) or available at a local or remote path.


File selection via this solution is available with a button in the "new send job" view:

NewJobFileSelection DLName.png

Receiving jobs to available DLNames is possible via a dynamic DLName selection:

FetchJobFileSelection DLName.png

Requirements

For this functionality, you need:

  • OS4X Webaccess Webbrowser plugin version 1.4.0 and up
  • Configured environment for local processing
    • All commands must be configured for the used environment in the used operating system

Supported operating systems:

  • Windows
  • Linux
  • Mac OS X
  • generic "other" operating systems, addressed via "unsupported operating system"

Executability of the configured programs/scripts must be given.

Configuration

Enable the configuration option "Enable local client process execution" in "Configuration" -> "OS4X Enterprise", section "OS4X Webaccess":

Enable local client process execution.png

When enabled, a tabbed panel offers the configuration of the script/program location for every platform. In case that the platform cannot be selected correctly, the fallback "Other" will be used.

Supported script locations

There are two modes for script locations:

  • Web locations: starting with "http", these locations will trigger a special logic by downloading them to the client in case of execution. The download location is a temporary location, whatever the operating system offers as a temporary path (may be influenced by user settings).
  • Local location: all configurations which don't start with "http" will start the configured script at the configured position. These must be locally available paths.

In case of a web location, the client checks if the location is approved by the user. For non-approved locations, the user will be prompted for the first time of access to the URL if he allows to download and execute the program/script from the given position.

Special files

In Windows, script types with the file extension ".vbs" will lead to an invocation of the Visual Basic interpreter in command line mode, which suppresses the opening of annoying command shell windows ("cmd.exe") during execution.

Script / Programs

There exist three configuration options for the following cases:

  • Environment listing script: tool to resolve environments usable by the client
  • DLName listing script: tool to deliver a list of directories, given in a special format also known as "DLName"
  • Export script: tool to export selected files in the used environment

Windows scripting hints

When dealing with the pipe symbol "|" scripting could be sometimes tricky. Be sure to escape the pipe for output in scripts. Example:

@echo off
echo dc_r1^|Daimler AG
echo pag^|Porsche AG
echo bmw^|BMW AG


Environment listing script

The environment list script will be executed dynamically on the client to list all available environment:

StreamingSmoke envList.png

Parameters:

  • none

Expected returncode:

  • 0: in case of success
  • non 0: in case of errors

Output (written to standard output ["stdout"]) must have the following line syntax:

<internal ID>|<Descriptor for GUI>

Lines may be seperated by linefeed or carriage-return/linefeed. The internal ID will be re-used later. The separator is the "pipe" symbol "|".

Example output:

dc_r19|Daimler AG
pag|Porsche AG
bmw|BMW AG

DLName listing script

The DLName listing script will be executed after selection of the environment in order to show all available directories/DLNames. All DLNames must be written to standard output, the output expected there will be used for the DLName list.

StreamingSmoke dlnames.png

Parameters:

  1. internal ID of the environment retrieved above

Expected returncode:

  • 0: in case of success
  • non 0: in case of errors

Output (written to standard output ["stdout"]) must have the following line syntax:

<DLName>;<Windows path>;<Unix (Mac, Linux; unsupported OS) path>;[<optionally: parent DLName>]

Lines may be seperated by linefeed or carriage-return/linefeed. The internal ID will be re-used later. The separator is the "pipe" symbol.

Example output:

00000000-START;d:\tmp;/catiav5/s1/mx/00000000;
DRAWINGS;d:\tmp\2d;/catiav5/s1/mx/2d;00000000-START
MODELS;d:\tmp\3d;/catiav5/s1/mx/3d;00000000-START

Multiple hierarchy steps are supported, as long as the referenced element is available above (say: in upper lines). DLNames must be unique!

Export script

The export script will be executed if:

  • the user double-clicks on an entry in the directory listing, leading to an export of the selected entity
  • the users clicks on the export button above the file listing

StreamingSmoke export.png

Parameters:

  1. internal ID of the environment retrieved above
  2. absolute path to input file
  3. absolute path to output file

Expected returncode:

  • 0: in case of success
  • non 0: in case of errors

Output (written to standard output ["stdout"]) will be attached to the plugin output (with a maximum size of 32kB) of the exported file in case of success. In case of unsuccessful export, the output will be used to display error messages to the user.

Format of input file

The input file will be a line-seperated list of files with absolute paths which are intended to be exported. Example:

D:\catiaV5\s1\env\mx\00000000\testfile1
D:\catiaV5\s1\env\mx\00000000\testfile2
D:\catiaV5\s1\env\mx\00000000\testfile3
D:\catiaV5\s1\env\mx\00000000\testfile4
D:\catiaV5\s1\env\mx\00000000\testfile5

Depending on the client's operating system, the input list contains windows or unix paths. Windows path information may include slashes ("/") instead of backslashes ("\") as directory separator.

Format of output file

The expected output file will be a line-seperated list of files with absolute paths. Each file, splitted on a new line, will be used to upload this file. The output file list must not be the exact copy of the input file list, so a dynamic behaviour can be implemented here. Example:

C:\temp\catiaV5_export.tar

The file upload mechanism will not delete any dynamically file, so it's your (asynchronous) task to delete these (possibly created) files on your own.

Logging

Local process execution and file handling will be logged in the plugin's logger, which writes its information to a defined location:

  • Windows:
%USERPROFILE%\AppData\LocalLow\OS4X\logs\StreamingSmokePlugin.log
  • Mac OS X:
$HOME/Library/Application Support/OS4X/logs/StreamingSmokePlugin.log