Data and Services Object Migration

External Service Object

The External Service Object in IRD is used to exchange data with third-party (non-Genesys) processes/applications that use the Genesys Interaction SDK or any other server/application that complies with the Interaction Server communication protocol.

Composer migrates this object to External Service block which is very similar to the IRD object and enables calling ESP APIs. It supports all properties exposed by the IRD object except for a behavior difference regarding user data input to the ESP API. The IRD object has a checkbox to disable sending userdata in the ESP call whereas Composer, by default, does not send userdata. Instead, userdata keys to be included in the ESP call need to be specified in the Composer block.

What needs to be done manually?

1. Specify UserData to be passed in the block as the entire userdata will no longer be passed in the ESP request.

IRD Source Property	Composer Block Property	Migration Transformation	Comments
Application type	None	No need for migration	IRD uses it as a UI filter to narrow down the list of applications. Composer displays application in a tree organized by application type.
Application name	Application	Property value is migrated without change	Both properties have the same semantics and intent. They point to an application defined in configuration server
Service	Service Name	Property value is migrated without change	Both properties have the same semantics and intent.
Method	Method Name	Property value is migrated without change	Both properties have the same semantics and intent.
Timeout Property	Service Timeout Property	Property value is migrated without change	Both properties have the same semantics and intent.
Parameters	Method Parameters	Property value is migrated without change	Both properties have the same semantics and intent.
Don't send user data	User Data	Not migrated	To optimize the ESP request, Composer requires relevant user data keys to be specified.
Result Tab	Result Property	Not migrated unless IRD stored output to a variable	Composer uses other blocks to attach data and mapping results to variables.

Web Service Object

In IRD this object is used to invoke SOAP WebServices and get results that are then used in other parts of the strategy.

Composer migrates this object to the Web Service block. This block is very similar to the equivalent IRD object. It uses a WSDL file (specified as part of the project or a URL) to determine details of the SOAP WebService like available services, bindings, end points etc and exposes properties to pass in parameter values and retrieve results back into the application. In addition, this block also offers offline usage where the SOAP call is not made at runtime and instead user provided values are used for output parameters. It also provides access to the Web Services Explorer that can be used to test SOAP WebServices at design time without the need for a test call or interaction.

What needs to be done manually?

IRD does not store a WSDL service URL which is used by Composer to populate all the block properties. Therefore no properties are set automatically. Specify the WSDL URL in the Composer block and select other properties that are populated based on the WSDL URL.

IRD Source Property	Composer Target Property	Migration Transformation	Comments
WSDL Location	Service URL	None. The WSDL URL has to be specified manually in the Composer block. The IRD object does not retain the WSDL URL therefore the original URL will have to be entered again in the Composer block.	Both properties have the same semantics and intent.
Service name	Available Services	None. Both source and target properties are strings.
Method name	Operations	None. Both source and target properties are strings.
Method namespace	Target Name Space Uri (Hidden property)	None. Both source and target properties are strings.	In Composer Web Service block, Namespace gets automatically set from the parsed WSDL file.
SOAPaction	Soap Action (Hidden property)	None. Both source and target properties are strings.	In Composer's Web Service block, SOAPAction gets automatically set from the parsed WSDL file.
Request Parameters	Input Parameters	None. Both source and target properties are a list of either Variable or String.
HTTP Authentication (Anonymous / Basic)	Authentication Type	None. Both source and target properties are strings.	Digest Authentication is not supported in Composer
Name	Login Name	None. Both source and target properties are strings / / Variable names.	Authentication User name
Password	Password	None. Both source and target properties are strings / Variable names.	Authentication password
Assign output values to variables by mapping SOAP response values	Map Output Values to Variables.	String Value "AssignByKey" in IRD will be considered as True (Boolean) in Composer
Output Values	Output Result	None. Both source and target properties are a list of either Variable or String.	Output Params mapping can be done only when the "AssignByKey" option is chosen on the IRD side. Composer doesn't support "AttachByKey" option.

Note: As IRD doesn't have any option to choose HTTP methods, the Use Protocol property of the Composer Web Service block will always be set to "SOAP".

Database Wizard

In IRD, this object is used to query a database and the queried information can then be attached to the call or assigned to a variable.

Composer migrates this object to an instance of the DBData Block. The DBData block does not utilize DBServer unlike the equivalent object in IRD. Instead, it uses a set of server side pages (Java/JSP or ASP.NET/C#) that execute on the application server as part of the Composer generated application. This block uses a database connection defined in the Composer project that can be configured to use connection pooling transparently. It includes a visual query builder and a stored procedure call helper to visually design a query or to invoke a stored procedure and test it from within the block. If situation where the query is too complex to be created visually or is already available, it supports specifying a file containing a query to be used instead of a query framed using the query builder.

What is created automatically?

These siginificant differences in paradigm mean that the connection information is not migrated over. Instead migrated creates a DBData block, creates a text file containing the query from the IRD object and sets the DBData block to use this file. Stored Procedures calls are not migrated over automatically and should be specified using Composer's Stored Procedure Helper UI.

What needs to be done manually?

1. Check the SQL query written to the .sql file that the DBData block points to.
2. Create a Dababase connection using the Database Connection Manager. Set the DBData block to use this connection.

To see a list of supported databases, please consult online help in Composer.

IRD Source Property	Composer Block Property	Migration Transformation	Comments
SQL	SQL File Property set to a file containing the SQL statement	The SQL will be extracted and written to a .sql file. The DB Data block will point to this .sql file.
Access Point	Database connection.	Connection information is not migrated.	DBServer is no longer used. See post-migration manual steps.