Virtual Service Types

When you create a new virtual service, you specify a transport protocol and a message protocol that the service will use. This section provides additional information required for some service types.

Binary Services

If the service is using an unknown transport protocol, creating a binary service is the best solution. If Service Virtualization cannot understand the message format, it can record it in binary format, although it is not able to fully recognize the structure.

Back to top

COBOL over IBM CICS TS HTTP Services

If the client communicates with the service using COBOL messages over HTTP transport, such as IBM CICS Transaction Server web-aware applications for example, you can use the following protocols for service simulation. Both HTTP Proxy and HTTP Gateway agent types are supported.

  1. COBOL messages over IBM CICS TS HTTP

    1. The client is any application using COBOL messages based on known COBOL copybook(s).
    2. The virtual service is created based on HTTP URI path.
    3. The message is fully structured.

  2. Binary messages over HTTP

    1. The client is any application using any messages (including COBOL).
    2. The virtual service is created based on HTTP URI path.
    3. The message is not structured. Only HTTP headers are shown.

COBOL services over IBM CICS TS HTTP transport usually use two encodings – one encoding for the HTTP protocol and the other for the COBOL messages. Service Virtualization expects the HTTP transport to be encoded using US-ASCII. However, the exact COBOL message encoding may be selected during virtual service creation.

Back to top

FIX Services

You can simulate FIX services over the WebSphere MQ transport protocol.

  1. Prerequisite: Before you create a FIX virtual service, make sure you have configured a Service Virtualization agent. For details, see Configure agents.

  2. Create a virtual service in one of the following ways:

    • Provide a service description to use your own FIX dictionary using QuickFIX XML format.
    • Select one of the FIX dictionaries provided by Service Virtualization.

    For details, see Create a Virtual Service.

  3. Add operations to the virtual service in one of the following ways:

Back to top

IBM CICS TG Services

You can virtualize any clients that use the IBM CICS TG SDK libraries to communicate with the IBM CICS Transaction Gateway.

Note: The IBM CICS TG agent is an early access feature. For more details, see Early access features.

The following is an overview of the supported CICS TG SDK message types:

  • ECI – External Call Interface (for better user experience select a COBOL copybook when creating a virtual service).
  • EPI – External Presentation Interface (no COBOL copybook involved).
  • ESI – External Security Interface (no COBOL copybook involved).

When creating an IBM CICS TG virtual service, you need to specify the corresponding IBM CICS TG agent. You can further specify an optional message filter based on the Server Name, Program Name, or Transaction ID, which enables you to distribute the traffic among several virtual services.

Back to top

IBM IMS TM Services

Depending on the client transport and message level protocol, there are multiple options for virtualizing IBM® Information Management System Transaction Manager (IMS™ TM) services.

The following is an overview of protocols with full message structure parsing. Each requires a COBOL copybook.

  1. COBOL payload over IBM IMS TM Resource Adapter

    1. The client is J2EE application using IBM IMS TM Resource Adapter to access IMS TM.

    2. The payload are COBOL messages based on known COBOL copybooks.

    3. The virtual service is created based on one or more of the following: TPipe name, Client ID, Datastore Name, Transaction Code.

  2. COBOL payload over IBM IMS Connect API protocol

    1. The client is J2SE application using IBM IMS Connect Java API to access IMS TM.

    2. The payload are COBOL messages based on known COBOL copybooks.

    3. The virtual service is created based on one or more of the following: LTerm name, Client ID, Datastore Name, Transaction Code.

If full message structure parsing is not required, or if the COBOL copybook is not available, the following protocols provide the best alternatives. Note that the payload is a binary object and not structured.

  1. Binary messages over IMS

    1. Any client type using IMS TM over a TCP/IP network.

    2. Any payload type.

    3. The virtual service is created based on one or more of the following: TPipe name, Client ID, Datastore Name, Transaction Code.

  2. Binary messages over WebSphere MQ

    1. The client is using IMS-MQ bridge to access IMS TM.

    2. Any payload type.

Back to top

REST Services

There are several ways to design REST services.

Record the real service: After you create a new REST virtual service, you can record real service behavior to learn the structure of the service.

Import OpenAPI specification: You can also use OpenAPI (Swagger), the JSON-based format for describing REST APIs, to create a REST service. You create a new virtual service by importing your swagger file and associated .json files.

The following parts of the OpenAPI standard are supported:

  • Service location metadata
  • Uri paths
  • Request headers, request message body, query parameters, path parameters
  • Response headers, response message body
  • JSON references
  • Inheritance

The following parts of the OpenAPI standard are NOT supported:

  • Most constraints that can be placed on data types are not supported, such as patterns, enumerations, min & max values, and min & max array items.
  • XML-based messages

Run HTTP Service Discovery: Run HTTP Service Discovery to record communication passing through the HTTP(S) Proxy agent, and then create new REST virtual services based on the discovered services.

Service Virtualization supports batch processing for OData version 2.0. Batch requests allow you to group multiple operations within a single HTTP request payload. When a POST request is received at the …/$batch path, with a content-type header value of multipart/mixed, Service Virtualization breaks down the incoming batch to child requests and learns or simulates the requests sequentially. Service Virtualization also supports referencing requests (using content-ID headers) and basic all-or-nothing transaction behavior.

Back to top

SAP IDoc and SAP RFC Services

You can import RFC functions or IDoc operations from a SAP server, or learn the functions and operations by recording real service behavior.

Service Virtualization supports the following:

  • SAP RFC or SAP IDOC communication between two SAP® servers or between a SAP server and a SAP NetWeaver® Process Integration (PI) system.
  • TCP/IP SAP destination only.
  • Only basic authentication for connection to a SAP system.
  • Supported RFC communication includes synchronous, or any of the three asynchronous types (Asynchronous, Transactional, or Queued). In the case of asynchronous types, requests are collected and then processed in a batch.

Back to top

SOAP Services

You can create SOAP services in the following ways:

  • Import WSDL documents directly into Service Virtualization to describe SOAP services. To later update a SOAP service description, you can load a new service description document.
  • Import a schema from an .xsd file.
  • Create a new service without importing a service description. You can then place the virtual service in Learning mode to record real service behavior.
  • Run service discovery to discover all the services used by an application.

Back to top

SQL Services

You can create virtual SQL services for working with JDBC. A virtual SQL service can simulate both J2SE and J2EE client applications.

When you configure the Service Virtualization JDBC agent to work with JDBC services, you enter parameters for the specific target environment in which you are working. Service Virtualization then configures a unique agent for your system.

Back to top

SWIFT over WebSphere MQ Services

You can simulate SWIFT services over the WebSphere MQ transport protocol for MT or MX messages.

Currently, only SWIFT over Intrusive WebSphere MQ services are supported.

  1. Prerequisite: Obtain a SWIFT license and licensed SWIFT .xsd schemas.
  2. Configure an Intrusive WebSphere MQ Service Virtualization agent. For details, see Configure the WebSphere MQ agent.

  3. Do the following:

    MT messages

    1. Create a virtual service for SWIFT over WebSphere MQ. For details, see Create a Virtual Service.

      Select at least two .xsd schemas for MT messages—one for the message type, for example, MT202, and one for the MT envelope.

    2. Add operations to the virtual service. For details, see Service Description Editor.
    MX messages

    Create a virtual service for SWIFT over WebSphere MQ. For details, see Create a Virtual Service.

    (.xsd schemas are not relevant for this message type.)

  4. Do one or more of the following:

Failure recovery: If you send an incorrect MT/MX message, the message is processed as a binary message.

Back to top

XML Services

In addition to creating an XML virtual service to simulate a real XML service, you can also create an XML virtual service to simulate a SOAP service. You can import an .xsd file when creating the virtual service.

Refer to the ISO8583 jPOS Bridge Configuration Guidefor instructions on how to virtualize the ISO 8583 protocol using an XML virtual service.

Back to top