JOpera for Eclipse

10.1: WSDL Import Wizard

The WSDL Import Wizard gives the user the possibility to customize the generated OML file. This section will explain in depth the different options and what they generate. It also explain what are the limitation of the importer as not every WSDL file can be imported successfully.

10.1.1: The WSDL File and import Options

Figure 10.1: Basic parameters and import options

The first page of the Import Wizard is used to define the basic parameters needed to import a WSDL File. The different input parameters are:

• Container

  The Container is the destination project to store the generated OML file. The Project can also be selected with the "Browse" Button situated to the right of the entry field.

• URL or File

  This is where the input WSDL file path has to be entered. The Format of the path has to be a complete URL (meaning with protocol). If the WSDL file is stored offline on the Computer, it can also be entered directly or through the "Browse" Button situated to the right of the entry field.

• Target OML File

  This is where the generated OML file will be saved to. Every time the URL changes, a default destination will be generated by the wizard. It can be changed afterwards to accomodate the needs of the user.

Furthermore, there are some options that have to be selected.

• Connection Type

  The Connection Type defines what kind of operations should be extracted from the WSDL file. Depending on the type, different JOpera adapters will be added to the program. At least one connection type has to be selected (or there will be no operations to import).

• Input Format

  If a program that is generated from an operation needs complex input parameters, two different input scheme can be used. The Leaves Only mode will generated an input field for every parameters that can contain a value, indipendent on the structure of the input message. It is then the responsability of the different adapters to handle the recreation of the complex type.
  
  The With Packer Mode on the other hand will generate one input field for every input parameter in the message indipendent on the type of the input (simple or complex). The adapters have to create packers that will create the complex type given the underlying input parameters. The packer structure can, of course, be recursive if the underlying parameters are themselves complex types.

• Output Format

  If a program that is generated from an operation needs complex output parameters, two different output scheme can be used. The Leaves Only mode will generated an output field for every parameters that can contain a value, indipendent on the structure of the output message. It is then the responsability of the different adapters to handle the extraction of the complex type.
  
  The With Unpacker Mode on the other hand will generate one output field for every output parameter in the message indipendent on the type of the output (simple or complex). The adapters have to create unpackers that will extract the the underlying output parameters given the complex type. The unpacker structure can, of course, be recursive if the underlying parameters are themselves complex types.

10.1.2: Selecting the Operations

Figure 10.2: Selecting the different operations

If the user wants to select which operations should be imported and which should not, he can use the next button instead of the finish button. The wizard will then show a list of the different operations found in the WSDL file preceded by the connection type to differentiate operations with the same name but different access modes.

Using the different buttons between the two lists, the User can then select the operations to import. The Selected Operations will be imported and the Available Operations have been found in the WSDL but won't be imported in the JOpera OML project.

• the < button will add the selected chosen methods to the available ones
• the << button will add all chosen methods to the available ones
• the > button will add the selected available methods to the chosen ones
• the >> button will add all available methods to the chosen ones

10.1.3: Warnings, Errors and Interpretations

A lot can go wrong when importing a WSDL file and the different operations. Some errors may result in the OML file being empty (e.g. not finding the WSDL file), other may result in the OML file having less programs then the number of chosen operations (e.g. the message format of an operation could not be imported).

To understand what went wrong, the user can select next instead of finish and see the different warnings and errors that happened on importing the WSDL file.

Figure 10.3: Viewing the Warnings and Errors

The Panel is separated into two categories.
The first part is a list of all errors and warnings that happened during the import.
The second part is a more detailed explanation of the message if one was found and where the message occured.

10.1.4: Known Limitations

The WSDL Import Wizard has limitations as the numbers of different WSDL files are theoreticaly endless and we could not cover every eventuality. The importer can only be made more powerful with feedback from user with WSDLs that crashed or were not satisfactorily imported. Some of them have already been found and known limitations are listed here.

• Schema import chain

  There is a problem when more than one schemes are defined in a WSDL file and one (or more) is referencing another one. The referenced message part will not be found and will be defined as a string. The responsability will then fall onto the programmer to find the right format for the parameter.

• 'Leaves only' output format

  The Leaves Only output format changes the way the output parameters are mapped to the output fields. This can only be done by upgrading the JOpera runtime. Until the runtime has been updated, this option will be set to disabled.

• Optional Input/Output Parameters

  Some WSDL files create choices by declaring two or more optional message parts. This can be done by setting the MinOccurs to 0. However creating optional message parts in JOpera is as yet not possible because it would need the runtime to be changed. Until the runtime has been updated, all optional fields will be inserted as if they were mandatory and the user must edit the input/output messages himself.

• Unbounded Input/Output Parameters

  Some WSDL files create arrays by declaring an element to have a maxOccurs of unbounded (or greater than 2 for that matter). The importer cannot as yet handle such fields and will only add one parameter for each declaration instead of an array declaration.

• Cycles in the definitions

  Some WSDL files creates definitions with elements referencing each others (e.g. an articles has n citations which are themselves articles with citations etc). The importer cannot handle Cycles in the Leaves Only mode.

• Input Element Attributes

  Some WSDL files creates elements with attributes instead of sub elements. In the Packer mode, those attributes cannot be properly processed and will be added to the parent Packer or to the Program if the element is defined there.

• Output Element Attributes

  Some WSDL files creates elements with attributes instead of sub elements. In the Unpacker mode, there is no way to extract the attributes from the element so an Unpacker will not be created for elements with attributes.

• HTTPS

  WSDL files found at HTTPS URLs may not be successfully imported unless your Java/Eclipse environment is correctly configured for SSL.

10.2: Autoconnection

JOpera takes an existing data flow graph and attempts to add data flow bindings between matching parameters. The user can access the feature by double-clicking on a parameter or by selecting some tasks and/or parameters and then right-clicking and choosing 'Auto Complete', Automatically Connect Parameters.

Figure 10.4: Context Menu Selection

On an empty selection every possible connection is added to the process displayed. If the user has selected a parameter, this parameter is auto-connected and if the user has selected a task the parameters of this tasks are auto-connected. It is possible to configure in the preference dialog if hidden parameters should be connected too and if already connected parameters should be ignored. Depending on if type information are visible or not this feature matches parameters only by name or by name and type information.

Figure 10.5: Preferences Dialog

Figure 10.6: Preferences Dialog

Figure 10.7: Autoconnect Example before

Figure 10.8: Autoconnect Example after

10.3: Refactoring

10.3.1: Upgrade/replacement of programs and processes

JOpera supports the replacement of service interfaces (e.g., when a service is upgraded to a new version with small modifications). The feature is accessible through the context refactor submenu (Figure Figure 10.9).

Figure 10.9: Context Menu Selection

The Program/Process Browser (Figure Figure 10.10) assists the user in choosing the new program/process (interface). The user may choose in the wizard (Figure Figure 10.11) if only the selected occurences or all matching ones are switched to the new interface.

Figure 10.10: Program Browser

Figure 10.11: Refactoring Wizard

10.3.2: Extract sub-process

The user may select a set of services in any of the views including the control flow of a process and choose to apply the process extraction refactoring (Figure Figure 10.12). The user's selection is reduced to tasks and constants. This implies that the user can select tasks and constants by drawing rectangles. Selected parameters are then ignored.
The user may choose the new Process' name in the Wizard (Figure Figure 10.14: left). A new process is created with the selected content, which is replaced by a SubProcess referencing it in the original process (Figure Figure 10.15: middle and right).

Figure 10.12: task and constant selection

Figure 10.13: Context Menu Selection

Figure 10.14: Refactoring Wizard

Figure 10.15: Dataflow of parent process after

Figure 10.16: Dataflow of extracted SubProcess

10.3.3: Inline sub-process

Inlining is the inverse to extracting, whereby a SubProcess is replaced by the content of the referenced Process. The user may select a subprocess and select the inline refactoring in the context refactor submenu (Figure Figure 10.17).

Figure 10.17: Context Menu Selection

The user may decide on the scope of the refactoring which can be either selection, file, project or workspace. Choosing the workspace scope the user can decide if the inlined process should be deleted automatically afterwards.

Figure 10.18: Refactoring Wizard

Figure 10.19: Dataflow of parent process after

10.4: JOpera Kernel Command Line Reference

By opening the JOpera Kernel Console view, you can access the low-level, command line interface of the JOpera process execution kernel. From it, you can bypass some of the GUI to directly access some of the internals of the kernel.

Figure 10.20: The JOpera Kernel Console view

This is recommended only for expert users that are trying to debug the system, develop additional functionality (and have not exposed the new features through a more user friendly UI). In this section we document some of the command lines that are currently supported by the JOpera Kernel Console view.

10.4.1: Starting processes

start 'processName' ['inputParameterValues']	This command starts the execution of a new process
processName	This is the name of the process to be started
inputParameterValues	Input Parameters are passed using a URL/CGI encoding

On the command line, the inputParameterValues are listed using a URL/CGI encoding. That is, the input parameters are passed as a list of name=value pairs, separated by the

&

character. Once a process has been started, it is assigned a unique ID by the system, which can be used throughout its lifetime to refer to it. This ID is printed out in the console view.

Examples

• start demo

  This will start a process called demo and use the default values for its input parameters

• start demo a=123&b=Test

  This will start a process called demo and pass the value 123 into its a input parameter and assigns the value Test to the b input parameter

10.4.2: Deleting process instances

delete data 'processID'	This command deletes the execution state of the given process instance
processID	This parameter identifies the process instance to be deleted

The processID identifies the process instance to be deleted. This is the value printed out after a process has been started using the start command.

Examples

• delete data demo.0.0

  This will start instance 0 of a process called demo

10.4.3: Listing deployed process templates

show templates	This command lists the names of the currently deployed processes

Examples

• show templates

  This will list all processes that are currently deployed in the kernel

10.4.4: Undeploying process templates

delete template 'processName'	This command undeploys a process template from the kernel
processName	Process templates are identified by name

The processName identifies the process template to be undeployed.

Note: Processes should only be undeployed if there are no active (running) instances, otherwise the kernel may be left in an inconsistent state

Examples

• delete template demo

  This will undeploy the process template called demo.