More about Service dotNet rules

Important: Service dotNet rules are no longer being actively developed, and are being considered for deprecation in upcoming releases. Using Service dotNet rules does not follow Pega development best practices. Use Service SOAP rules instead. For more information, see Service SOAP rules.

WSDL generation

After you have created all the Service dotNet rules for a package, open the Service Package data instance to create a WSDL file. You can copy the generated WSDL file to the client (calling) system to support deployment.

Debugging tips

Use the Tracer to debug Service dotNet rules. You can use the built-in monitor tool from AXIS known as TCPMon to trace SOAP messages. See More about Service SOAP rules.

HTTP messages sent by Pega Platform might be compressed and difficult to review in Tracer displays. You can turn off data compression. See Tracer best practices.

Production

The Service dotNet rules run in a background requestor that uses the PRSOAPServlet servlet.

At runtime, the package, class, and method names are passed in as part of a SOAP request so that Pega Platform can look up the corresponding Service dotNet rule and execute the specified activity.

Authentication

When Requires authentication? is specified in the service package instance, Service SOAP rules support HTTP Basic Authentication. If your situation requires WS-Security authentication, you can configure this through facilities of your application server. In that case, use Service EJB rules or Service Java rules rather than Service SOAP rules.

Stateful processing

When the Processing mode on the service package is set to Stateful, the PRSOAPServlet servlet uses token passing and cookies to maintain state between client and server.

Perfromance statistics

Through changes to the prlog4j2.xml file, you can obtain performance statistics on the execution of services. See Performance tool — Statistics for services.