You are here: Reference > Rule types > Service dotNet rules > More about Service dotNet rules

More about Service dotNet rules
 

  1. About 
  2. New 
  3. Service 
  4. Request 
  5. Response 
  6. Faults 
  7. XML Page 
  1. History 
  2. More... 

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 the Pega Platformmay be compressed and difficult to review in Tracer displays. You can turn off data compression. See Tracer — Troubleshooting.

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 the Pega Platformcan 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.

Performance statistics

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

About Service dotNet rules