Service Properties Page

This wizard page enables you to define protocol-specific properties for your virtual service.

Important information
  • General information about this wizard is available here: Create New Virtual Service Wizard
  • The properties available on the page depend on the protocols you select for the new service on the Choose Service Protocol page.
  • After the virtual service is created, you can edit these properties. In the Virtual Service Editor, under Service Configuration, click Edit to open the Edit Endpoints dialog box.
  • For additional details on specific service types, see Virtual Service Types.
Wizard map

The create new virtual service wizard contains:

Import Real Service Description Page > Choose Service Protocol Page > Service Properties Page > Summary of Virtualization Page
See also Virtual services

User interface elements are described below:

Field Description
Show Endpoint Topology

Displays a diagram of your service endpoint configuration.
Test Endpoints

Checks that the real service endpoints are accessible.

Define the real and virtual service properties.

Note: Each virtual service requires a unique agent configuration for each endpoint. For a virtual service, you need at least two configurations—one for the virtual service reading and one for virtual service writing. For a real service, you need two additional configurations—one for real service reading and one for real service writing.

Property Description
Virtual/Real Service
Request folder Select the Service Virtualization agent to use for incoming requests.
Response folder Select the Service Virtualization agent to use for outgoing responses.
Input/Output File/Patterns

The wildcard pattern to use for reading/writing files or filenames.

Default value: *.*

Wildcard options for input/output file patterns:

* (asterisk) - use in place of a filename or part of the filename

# (hash)

  • use in output pattern to create multiple output files based on one input file. Output files will be sequentially numbered.

    # - Integers 0-9

    ## - Integers 00-99

  • use in input pattern to match any integer

    Note: To use an actual '#' character, it must be escaped by using "\#".

Examples of input > output:

*.jpg > *.png - The filename stays the same but the extension is changed.

*ABC.xml > *CDE.xml - Any filename ending in "ABC" with a ".xml" extension is read and stored on output as [string_before_ABC]CDE.xml. For example, newfileABC.xml > newfileCDE.xml

*.xml > output##.xml - Any file with ".xml" extension is read and stored on output as "output[00-99].xml”. For example, abc.xml > output00.xml, abb.xml > output01.xml.
After output99.xml, the sequence is reset and the next output file is output00.xml again.

*#.txt as an input pattern matches, for example, hello1.txt, payment7.txt, etc.
Use Real Service Use real service endpoints. When not selected, you don't need to configure the real service endpoints since they are not being used. Such a service can only be used in simulation mode. Use this option when you create a virtual service without a real service or when the real service is not yet available.
Service properties
Request Mode

Specifies how the virtual service reads new or modified files:

  • Full - reads full file content.
  • Incremental - reads appended content only.

Default value: Full
Response Mode

Specifies how the virtual service writes outgoing files:

  • Full - writes full content into the output file. (If the file already exists, the new content overwrites the old content.)
  • Incremental - responses are appended to the end of the output file.

Default value: Full
Request and response modes differ Check this checkbox to enable choosing different values for Request Mode and Response Mode.
File filters
Filter by time

If selected, the virtual service processes only the files that are older than the defined value.

Default value: 00:00:00 (processes every change)

Examples: 00:01:00 (one minute), 12:13:14, (12hrs, 13min and 14secs)
Filter by size

If selected, the virtual service processes only the files or changes that are larger than the defined value.

Possible values: 0-2147483647

Default value: 0 (processes every file)
Additional settings
Delete files after processing

Deletes files after they are processed by the virtual service.

Possible values: True, False

Default value: False
Additional settings for CSV over file system
Multiple rows per message Select this to send all CSV rows in one message, instead of sending each row in a separate message.
First row as header

Select this if the first row in the CSV file is a header row.

Possible values: True, False

Default value: False
Delimiter

Indicates the delimiter between columns in the CSV file.

Possible values: Any string.

Default value: , (comma)
Additional settings for Text-delimited over file system
Message delimiter

Indicates the delimiter between messages.

Possible values: Any string. When using special characters, this parameter must be encoded.

Default value: \r\n (carriage return + newline symbol)
Field delimiter

Indicates the delimiter between fields.

Possible values: Any string. When using special characters, this parameter must be encoded.

Default value: ; (semi-colon)
Value delimiter

Indicates the delimiter between key-value pairs.

Possible values: Any string. When using special characters, this parameter must be encoded.

Default value: =
Field as a prefix

Switches between text-delimited formats. The value of the prefix is used as the field name.

Possible values: True, False

Default value: False
Prefix size

The size of the prefix.

Possible values: 0-2147483647

Default value: 0

When creating a FIX service:

  1. Select the schema that corresponds to the FIX version you are using.

  2. Define virtual and real service properties according to WebSphere MQ.

Define the real and virtual service endpoints.

Note: You can configure virtual services without real service endpoints.

Property Description
Virtual Service Path

The URI path of the virtual service.
Use Real Service

Use real service endpoints. When not selected, you don't need to configure the real service endpoints since they are not being used. Such a service can only be used in simulation mode. Use this option when you create a virtual service without a real service or when the real service is not yet available.

Real Service Endpoints

The real service endpoint (URL).

Define the real service endpoints.

Property Description
Endpoints

The real service endpoint (URL).

To enter multiple endpoints, separate them by a space, comma, semicolon, or type each endpoint on a new line.

Optionally define the real service properties to narrow down the range of virtualized services. Values are case-sensitive.

Property Description
Server The mainframe server name.
Program The mainframe server program name.
Transaction The mainframe server transaction ID.
Any value Clear this option to define a filter for the corresponding property. If you enter a specific value for a property, only messages matching the specified value are processed during Learning and Simulation sessions.

Define the real service properties. Values are case-sensitive and should be provided by your IMS TM System Administrator or Operator.

Property Description
Client ID Identification of the client for services with dedicated persistent socket connections. For shareable persistent socket connections, leave this value undefined.
Transaction Code The alphanumeric code used to invoke IMS message processing program.
TPipe Name The transactional pipe (TPipe) value, used to maintain a logical association between client and service. The OTMA TPipe name is similar to the IMS Connect logical terminal (LTerm) name.
LTerm Name Logical Terminal Name. The IMS logical association between client and service. Similar to OTMA TPipe name.
Datastore ID The service datastore name (IMS Destination ID).
Any value Clear this option to define a filter for the corresponding property. If you enter a specific value for a property, only messages matching the specified value are processed during Learning and Simulation sessions.

Define virtual and real service properties.

Property Description
Virtual Service Parameters:
Path The relative URI  that defines on which URI path the virtual service is to be deployed.
Real Service Properties:
Endpoint

The relative or absolute endpoint, depending on the agent type, that defines where the actual COBOL service is listening. For details, see Virtual Service Types.
Encoding COBOL content encoding.

Define the virtual service properties.

Property Description
Agent

Select an agent on which to deploy the virtual service, and the server on which the agent is deployed.

Click Manage Agents if you want to define a new agent or modify an existing configuration.
Virtualized Classes

Enter the names of the classes or methods that you want to virtualize.

If you do not specify a method for a class, all methods in the class will be virtualized.

These classes are used by the Java Instrumentation Agent (HP.SV.JavaInstrumentator.jar). For more details, see Configure the Java agent.
New Class Adds a new class to the virtual service. Double-click the class name to edit.
New Method Adds a new method to the virtual service. Double-click the method name to edit.
Remove Select the class or method you want to delete and click Remove.

Define the real service properties.

Property Description
Connection String

Define one of the following:

  • The JDBC Connection string used in the application under test. This is used primary when working with J2SE applications.
  • The JNDI datasource name used by the application under test. This is used only if the application is deployed on a J2EE application server.

Define virtual and real service properties.

Note: You can configure virtual services without real service endpoints.

Virtual Service Properties:
Multiple Agents

Select Enable multiple JMS providers to enable the use of different JNDI contexts for incoming/outgoing messages or for request/response activities.

  • You can define an agent configuration for each JNDI context you require. For details, see Agent user interfaces.

  • Select agent configurations for your virtual service using the Agent and Reply Agent fields in this dialog box. A virtual service has virtual and real service endpoints, and each endpoint has an input and an output agent, resulting in four possible agent assignments.

Example:  

The following use cases are examples only. You can configure the agents in any combination to meet your needs.

  • Use one agent configuration (agent 'A') for handling communication for request processing, and another agent configuration (agent 'B') for handling communication for response processing.

  • Use one agent configuration (agent 'A') for communication between your client (AUT) and Service Virtualization, and another agent configuration (agent 'B') for communication between Service Virtualization and the real service.
Server

The Service Virtualization Server on which you want to deploy the virtual service.

Available when using multiple agents.
Request Agent

Used for processing requests from the client to Service Virtualization.

Available when using multiple agents.
Request Destination

The JNDI destination name where the virtual service expects to receive requests.

*A special destination format is required for RabbitMQ. See below for details.
Connection Factory The JNDI name of the connection factory used for communication from the client to Service Virtualization.
Response Agent

Used for processing responses sent from Service Virtualization to the client.

Available when using multiple agents.
Response Destination

The JNDI destination name where the virtual service will send responses.

  • If the client provides a ReplyTo JMS property, you can leave this field empty.
  • If you are using multiple agents, this field must not be left empty.

*A special destination format is required for RabbitMQ. See below for details.
Reply Connection Factory

The JNDI name of the connection factory used for communication from Service Virtualization to the client.

Available when using multiple agents.
Use Real Service

Use real service endpoints. When not selected, you don't need to configure the real service endpoints since they are not being used. Such a service can only be used in simulation mode. Use this option when you create a virtual service without a real service or when the real service is not yet available.

Real Service Properties:
Request Agent

Used for processing requests from Service Virtualization to the real service.

Available when using multiple agents.
Request Destination

The JNDI destination name where the real service expects to receive requests.

*A special destination format is required for RabbitMQ. See below for details.
Connection Factory The JNDI name of the connection factory used for communication from Service Virtualization to the real service.
Response Agent

Used for processing responses sent from the real service to Service Virtualization.

Available when using multiple agents.
Response Destination

The JNDI destination name where the real service sends responses.

  • If this field is left empty, Service Virtualization creates a temporary destination for receiving responses from the real service, and sets the ReplyTo JMS property in the request to point to that temporary destination.
  • If you are using multiple agents, this field must not be left empty.

*A special destination format is required for RabbitMQ. See below for details.
Reply Connection Factory

The JNDI name of the connection factory used for communication from the real service to Service Virtualization.

Available when using multiple agents.

*Special RabbitMQ Destination format:

[exchangeType]/exchangeName<+flags>/queueName<+flags>/routingKey

Where

  • exchangeType: "direct", "fanout", "topic", "headers"

  • exchange flags: "D" = durable, "A" = autodelete

  • queue flags: "D" = durable, "E" = exclusive, "A" = autodelete

For example: direct/demo.rpc+D/demo.rpc.requests+D/rpc.demo

Define virtual and real service properties.

Note: You can configure virtual services without real service endpoints.

Property Description
Use Authentication

Select Use Authentication for any element to enable domain authentication. You must use authentication when working in a domain environment in which an MSMQ queue restricts access to authenticated users.

The user that is configured to run the Service Virtualization Server or Designer is used for all authentication to MSMQ servers and resources. Authorization is carried out by Windows Active Directory.
Virtual Service Properties:
Multiple Agents

Select Enable multiple queue managers to enable the use of different MQ queues for incoming/outgoing messages or for request/response activities.

  • You must define an agent configuration for each queue you require. For details, see Agent user interfaces.

  • Select agent configurations for your virtual service using the Agent and Reply Agent fields in this dialog box. A virtual service has virtual and real service endpoints, and each endpoint has an input and an output agent, resulting in four possible agent assignments.

Example:  

The following use cases are examples only. You can configure the agents in any combination to meet your needs.

  • Use one agent configuration (agent 'A') for handling communication for request processing, and another agent configuration (agent 'B') for handling communication for response processing.

  • Use one agent configuration (agent 'A') for communication between your client (AUT) and Service Virtualization, and another agent configuration (agent 'B') for communication between Service Virtualization and the real service.
Server

The Service Virtualization Server on which you want to deploy the virtual service.

Available when using different request/response agents.
Request Destination

Name of queue where the virtual service expects requests.

Click Browse to select a destination or to virtualize a destination.

Note: The Browse option is available only if your virtual agent has the necessary permissions, which are granted by the MQ administrator. For details, see MQ authentication.

If the Browse option is unavailable, you can manually enter the request destination and click Test Endpoint to make sure it is correct.
Request Agent

Used for processing requests from the client to Service Virtualization.

Available when using different request/response agents.
Response Destination

Name of queue where the virtual service will send responses. If the client provides a ReplyToQueue message property, you can leave this field empty.

Click Browse to select a destination.
Response Agent

Used for processing responses sent from Service Virtualization to the client.

Available when using different request/response agents.
Use Real Service

Use real service endpoints. When not selected, you don't need to configure the real service endpoints since they are not being used. Such a service can only be used in simulation mode. Use this option when you create a virtual service without a real service or when the real service is not yet available.

Real Service Properties:
Request Destination

Name of queue where the real service expects requests.

Click Browse to select a destination.
Request Agent

Used for processing requests from Service Virtualization to the real service.

Available when using different request/response agents.
Response Destination

Name of queue where the real service sends responses. Click Browse to select a destination.

Note: This field may not be left empty.
Response Agent

Used for processing responses sent from the real service to Service Virtualization.

Available when using different request/response agents.

Define the following properties for the request queue, and optionally, for the response queue.

Property Description
Subscription Agent Name The AQ Agent name that Service Virtualization uses to consume messages.
Queue Name The name of the AQ queue.
Dequeue Condition A condition you can define to limit messages consumed by Service Virtualization.

Define the virtual and real service properties according to the HTTP Gateway and HTTP Proxy sections.

Define real and virtual service settings.

Property Description
Virtual Service Settings
Program ID The ID assigned to the RFC destination defined on the SAP or PI server.
Source SAP in Unicode Indicates that the RFC destination you are using is Unicode enabled.
Source SAP PI Indicates that you are working with a SAP PI RFC adapter.
Real Service Settings
Hostname

The IP address or host name of the SAP server.

Alternatively, you may enter the SAP Router String for communication through the SAP firewall.
Gateway

The SAP Gateway.

The gateway is "sapgwXX", where XX is the SAP system number.
Client ID The SAP client ID.
Target SAP in Unicode Indicates that the destination SAP system is Unicode enabled.

Define real and virtual service settings.

Property Description
Virtual Service - Request Settings
Program ID The ID assigned to the RFC destination defined on the SAP or PI server.
Source SAP in Unicode Indicates that the RFC destination you are using is Unicode enabled.
Source SAP PI Indicates that you are working with a SAP PI RFC adapter.
Virtual Service - Response Settings (Optional)
Program ID The ID assigned to the RFC destination defined on the SAP or PI server. This destination is used for responses.
Source SAP in Unicode Indicates that the RFC destination you are using is Unicode enabled.
Source SAP PI Indicates that you are working with a SAP PI RFC adapter.
Real Service - Request Settings
Hostname

The IP address or host name of the SAP server.

Alternatively, you may enter the SAP Router String for communication through the SAP firewall.
Gateway

The SAP Gateway.

The gateway is "sapgwXX", where XX is the SAP system number.
Client ID The SAP client ID.
Target SAP in Unicode

Indicates that the destination SAP system is Unicode enabled.
Real Service - Response Settings (Optional)
Client ID The SAP client ID.
Target SAP in Unicode Indicates that the destination SAP system is Unicode enabled.

Define virtual and real service properties according to WebSphere MQ.

Define the real service properties.

Since Service Virtualization records messages on TIBCO EMS non-intrusively, all parameters in the configuration are related only to the real service. When the virtual service mode is switched to Simulating mode, the real service is automatically disconnected from TIBCO EMS and is replaced by Service Virtualization.

There is no response destination name as the response destination is always read from request properties.

Property Description
Destination Name Name of destination where requests are sent.
Destination Type Type of destination where requests are sent.

Define the service properties.

Property Description
Agent Select the agent for the new virtual service to use.
Virtualized Flow Service Name The name of the webMethods Integration Server flow service that you want to virtualize.
Virtualized Flow Step Name

The name of the webMethods Integration Server flow steps that you want to virtualize.

The virtual service can contain multiple steps from one flow service.

Define the real service properties.

Property Description
Request Service Name The webMethods Integration Server flow service that publishes requests.
Response Service Name The webMethods Integration Server flow service that processes responses.

The request and response service names must be formatted using full names, as specified in the webMethods IS documentation. For example:

SAP_EC6.services:ReqFlowService

Define the real service properties.

Property Description
Request Service Name The webMethods Integration Server flow service that publishes requests.
Virtualized Flow Step Name

The name of the webMethods Integration Server flow steps that you want to virtualize.

The virtual service can contain multiple steps from one flow service.

The request service and step names must be formatted using full names, as specified in the webMethods IS documentation. For example:

Service: MyRFC:MyRFCService

Step: MyRFC:RFC

Define virtual and real service properties.

Note: You can configure virtual services without real service endpoints.

Property Description
Virtual Service Properties:
Multiple Agents

Select Enable multiple queue managers to enable the use of different MQ managers for incoming/outgoing messages or for request/response activities.

  • You must define an agent configuration for each queue manager you require. For details, see Agent user interfaces.

  • Select agent configurations for your virtual service using the Agent and Reply Agent fields in this dialog box. A virtual service has virtual and real service endpoints, and each endpoint has an input and an output agent, resulting in four possible agent assignments.

Example:  

The following use cases are examples only. You can configure the agents in any combination to meet your needs.

  • Use one agent configuration (agent 'A') for handling communication for request processing, and another agent configuration (agent 'B') for handling communication for response processing.

  • Use one agent configuration (agent 'A') for communication between your client (AUT) and Service Virtualization, and another agent configuration (agent 'B') for communication between Service Virtualization and the real service.
Server

The Service Virtualization Server on which you want to deploy the virtual service.

Available when using different request/response agents.
Request Destination

Name of queue where the virtual service expects requests.

Click Browse to select an actual destination or to virtualize a destination.

Note: The Browse option is available only if your virtual agent has the necessary permissions, which are granted by the MQ administrator. For details, see MQ authentication.

If the Browse option is unavailable, you can manually enter the request destination and click Test Endpoint to make sure it is correct.
Request Agent

Used for processing requests from the client to Service Virtualization.

Available when using different request/response agents.
Response Destination

Name of queue where the virtual service will send responses. If the client provides a ReplyToQueue message property, you can leave this field empty.

Click Browse to select an actual destination or to virtualize a destination.

Note: The Browse option is available only if your virtual agent has the necessary permissions, which are granted by the MQ administrator. For details, see MQ authentication.

If the Browse option is unavailable, you can manually enter the response destination and click Test Endpoint to make sure it is correct.
Response Agent

Used for processing responses sent from Service Virtualization to the client.

Available when using different request/response agents.
Use Real Service

Use real service endpoints. When not selected, you don't need to configure the real service endpoints since they are not being used. Such a service can only be used in simulation mode. Use this option when you create a virtual service without a real service or when the real service is not yet available.

Real Service Properties:
Request Destination

Name of queue where the real service expects requests.

Click Browse to select an actual destination or to virtualize a destination.
Request Agent

Used for processing requests from Service Virtualization to the real service.

Available when using different request/response agents.
Response Destination

Name of queue where the real service sends responses. Click Browse to select an actual destination or to virtualize a destination.

Note: If this field is left empty, Service Virtualization creates a temporary queue for receiving responses from the real service, and sets the ReplyToQueue message property in the request to point to that temporary destination.

If the field is left empty:

  • WebSphere MQ must be configured so that Service Virtualization has permission to create temporary queues.

  • The real service request agent (the Agent field) and the real service reply agent (the Reply Agent field) must be the same.
Response Agent

Used for processing responses sent from the real service to Service Virtualization.

Available when using different request/response agents.

Define real service properties.

Property Description
Real service properties
Multiple Agents

Select Enable multiple queue managers to enable the use of different MQ managers for incoming/outgoing messages or for request/response activities.

  • You must define an agent configuration for each queue manager you require. For details, see Agent user interfaces.

  • Select agent configurations for your virtual service using the Agent and Reply Agent fields in this dialog box. A virtual service has virtual and real service endpoints, and each endpoint has an input and an output agent, resulting in four possible agent assignments.

Example:  

The following use cases are examples only. You can configure the agents in any combination to meet your needs.

  • Use one agent configuration (agent 'A') for handling communication for request processing, and another agent configuration (agent 'B') for handling communication for response processing.

  • Use one agent configuration (agent 'A') for communication between your client (AUT) and Service Virtualization, and another agent configuration (agent 'B') for communication between Service Virtualization and the real service.
Server

The Service Virtualization Server on which you want to deploy the virtual service.

Available when using different request/response agents.
Destination Name

Name of queue where the real service expects requests.

Click Browse to select an actual destination or to virtualize a destination.
Agent

Used for processing requests from Service Virtualization to the real service.

Available when using different request/response agents.
Reply To

Name of queue where the real service sends responses. Click Browse to select an actual destination or to virtualize a destination.

Note: If this field is left empty, Service Virtualization creates a temporary queue for receiving responses from the real service, and sets the ReplyToQueue message property in the request to point to that temporary destination.

If the field is left empty:

  • WebSphere MQ must be configured so that Service Virtualization has permission to create temporary queues.

  • The real service request agent (the Agent field) and the real service reply agent (the Reply Agent field) must be the same.
Reply Agent

Used for processing responses sent from the real service to Service Virtualization.

Available when using different request/response agents.

Back to top