Avaya Interaction Center 7.2 Workflow Script Engine has support of calling Java functions from the Workflow Script. This solution is generic for Java function calls and is not specific for webservices.

For calling webservices, developers need to write a Java client which has the implementation of calling webservices and all WSDL related complexity will be handled in implementing this Java Client. Developers need to call this java client's function to eventually call webservice functions from the workflow script.

Developers need to enable "Enable Java Support For Script" from the Workflow Server's Workflow tab using Advanced property. This is followed by setting the Client Java Class Path in the configuration. Other JVM related configuration can be set if required.

The following steps are needed for using this feature:

• Write a new client Java class which either implements JICJavaBase or extends JICJavaAdapter class of <AVAYA_IC_HOME>/Java/jar/ICJavaInterface.jar package. In this client java class you need to put the implementation of calling webservices functions in one of the following functions:
  • String invokeICJava(String)
  • void invokeICJavaVoid(String)
  • JSeqCouple invokeICJava(JSeqCouple)
  • void invokeICJavaVoid(JSeqCouple)
• Compile and package your client java code once your implementation of calling webservices is completed.
• Go to the Workflow server configuration's Workflow tab in IC Manager and select Advanced Properties. Enable "Enable Java Support For Script" and set JVM options (including classpath of your client java package created in step 1). You need to provide the Library path only if your client java code is using external libraries. Otherwise you should leave it blank.
  Note : Do not provide the classpath of <AVAYA_IC_HOME>/Java/jar/ICJavaInterface.jar as it will be loaded by JVM by default.
  
• Create workflow using new palettes of WebServices tab in workflow designer.
  

The following new custom extensions are supported in Workflow script with this feature:

• IsValidJavaClass :
  Type : Function
  Input Argument : String - ClassName
  Output : Boolean - True on Success, False on Failure
  Min Arguments : 1
  Max Arguments : 1
• IsValidJavaClassMethod :
  Type : Function
  Input Argument : String - ClassName
  String - MethodName
  String - MethodSignature
  Output : Boolean - True on Success, False on Failure
  Min Arguments : 3
  Max Arguments : 3
• InvokeICJavaStr :
  Type : Function
  Input Argument : String - ClassName
  String - MethodArgument
  Output : String - OutputResult
  Min Arguments : 2
  Max Arguments : 2
  Type : Sub
  Input Argument : String - ClassName
  String - MethodArgument
  String - OutputResult
  Output : None
  Min Arguments : 3
  Max Arguments : 3
• VoidInvokeICJavaStr :
  Type : Sub
  Input Argument : String - ClassName
  String - MethodArgument
  Output : None
  Min Arguments : 2
  Max Arguments : 2
• InvokeICJavaSC :
  Type : Function
  Input Argument : String - ClassName
  SeqCouple - MethodArgument
  Output : SeqCouple - OutputResult
  Min Arguments : 2
  Max Arguments : 2
  Type : Sub
  Input Argument : String - ClassName
  SeqCouple - MethodArgument
  SeqCouple - OutputResult
  Output : None
  Min Arguments : 3
  Max Arguments : 3
• VoidInvokeICJavaSC :
  Type : Sub
  Input Argument : String - ClassName
  SeqCouple - MethodArgument
  Output : None
  Min Arguments : 2
  Max Arguments : 2

The recommended way to add an alarm to an existing block is to use the IC Script Editor, with the following guidelines.

• Always include the common name of the block
• Reference the common name by property blockName in the IC Script.
• Follow the common name with a simple one-word token that describes the reason for raising the alarm. Good examples of tokens are Error or Warning. In the example below "Error" is used as the one-word token.

A sample IC script to raise an alarm in the CreateEDU block, when an EDUID cannot be created is,

Toolkit.alarm {_#blockName} & "Error", "High", "Could not create EDU!"

This warning is received when there is about to be an update or modification on a standard block that is provided and maintained by Avaya. As Avaya periodically releases block updates, an upgrade utility will replace outdated blocks in catalogs and workflows. The following changes are lost when a block is upgraded:

• Changes to the IC Script of a block
• Addition/removal of properties
• Addition/removal of connection points

To avoid losing changes on an upgrade, it is recommended to only update or alter custom blocks. If changes to a standard block are required, the correct procedure is to make a copy of that block and create a customized version of the block. Extra details on customizing an existing block are available in the Workflow Designer User Guide.

Block dimensions must be a multiple of 10 plus 1. The recommended bitmap dimensions are:

• 41 x 41 pixels
• 41 x 61 pixels
• 61 x 61 pixels

All palette icon bitmaps must be 32 x 32 pixels.

Yes, to debug only one block in the workflow, set the following properties:

• Print statements - on
• Project debugging - on
• Workflow debugging - Set flowDebug property to custom
• Block to debug - Set blockDebug property to on
• All other blocks in the workflow - Set blockDebug property to off