Scribd
Upload
157 views2 pages

PEGA Session Notes

The document discusses session state in SOAP services, which can be stateful or stateless. In a stateful session, state is maintained between requests while in a stateless session, state is not maintained. The session semantics must match between the SOAP client and service configuration. Authentication can also be configured so the service runs as an authenticated or unauthenticated user.

Uploaded by

ahrenus D
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
157 views2 pages

PEGA Session Notes

The document discusses session state in SOAP services, which can be stateful or stateless. In a stateful session, state is maintained between requests while in a stateless session, state is not maintained. The session semantics must match between the SOAP client and service configuration. Authentication can also be configured so the service runs as an authenticated or unauthenticated user.

Uploaded by

ahrenus D
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 2

Session State

The session state of a SOAP session (stateless vs. stateful) is specified in two
places:
■ In the Process Commander service package
■ In the SOAP client application code that sets up the message context for the SOAP
message
The session semantics of the SOAP client and the service package must match. If
they do
not, you may get unexpected results when you test your service because session
state for
the service is determined by the service package, not the SOAP client:
■ If the SOAP client requests a stateless session but the service package is set to
stateful, the session is stateful and requestor pooling is disabled.
12 0BBuilding SOAP Services
■ If the SOAP client requests a stateful session but the service package is set to
stateless, the session is stateless and clipboard properties are cleared after the
service
completes its processing.
Stateful Sessions
When the session is stateful, the state of the clipboard remains intact between
requests.
You can specify the individual behavior of the requestor used by each service rule
in the
package, and the SOAP client can invoke multiple methods (service rules) during the
same session, as the same requestor if necessary. Each subsequent service rule has
access
to clipboard values that were set by a previous method (service rule).
Stateful sessions do not use requestor pooling.
The Process Commander application that you are making available through SOAP
services may require functions to occur in a specific sequence because subsequent
functions rely on data set earlier in a session. To implement session continuity,
configure
the service package and service rules as follows:
1. Set the Processing Mode field in the service package to Stateful.
2. In the service rules other than the one that ends the sequence, clear the End
Requestor check box, which keeps the requestor session open after the response is
sent.
3. In the last service rule invoked in the sequence of methods, select the End
Requestor check box, which closes the requestor session after the response is sent.
Note: If you do not select the End Requestor check box to close the requestor
session, the session remains open until another method closes it or the session
times
out.
Stateless Session
If the session is stateless, the service uses requestor pooling. The clipboard is
cleared for
the requestor when the service completes its response. Subsequent requests to the
same
service do not have access to any previous values.
However, the requestor pool does not include authenticated requestors (users).
Therefore,
when the session is stateless and the service runs as an authenticated user,
requestor
pooling is not available.
For more information about requestor pooling, see PegaRULES Process Commander
Integrating with External Systems.
0BBuilding SOAP Services — 2BThe SOAP Service 13
Authentication
A SOAP service can run as either an authenticated or an unauthenticated user.
Running as an Unauthenticated User
If you configure your SOAP service to run in a stateless, unauthenticated session,
the
SOAP client does not provide an operator ID. The rule session is assigned a
requestor ID
from the requestor pool created for the service. The access group specified in the
service
package is used for rule resolution.
Running as an Authenticated User
A Process Commander system can be configured to authenticate users in several ways,
as
described in the document Authentication in PegaRULES Process Commander, which is
available on the PDN. Therefore, your first step is to determine how the SOAP
service
requestors are to be authenticated. For example, if your Process Commander system
is
configured to authenticate users through container-managed authentication, should
the
SOAP service requestors (users) be authenticated in the same way?
To configure a SOAP service to run as an authenticated user, complete the following
steps:
1. Determine how SOAP service requestors are to be authenticated. If they are to be
authenticated by container-managed authentication, follow the instructions in
Authentication in PegaRULES Process Commander to configure the WebSOAP
servlet definition in the Process Commander web.xml file.
Note: Do not change the URL pattern for the WebSOAP servlet from its default
value of PRSOAPServlet. PRSOAPServlet is used as the end point URL specified
in the WSDL files generated for your SOAP services. If you change it in the
web.xml file, the end point URLs in the WSDL files will not match the URL of the
WebSOAP servlet on your system.
2. In the service package (Data-Admin-ServicePackage) on the Context tab, select
the
Requires Authentication option.
3. Code the SOAP client to provide the user name and password of a valid Process
Commander operator ID in the SOAP messages it sends. User name and password
values can be provided in any of the following ways:
− In the HTTP header, using HTTP Basic Authentication. The PRSOAPServlet
automatically recognizes authentication information sent in an HTTP header as
such.
14 0BBuilding SOAP Services
− As parameter values in the SOAP envelope header. If you choose this method,
use the WSDL file from the service package to determine the correct format for
the header and its contents.
− As parameter values in the SOAP envelope body.
4. Verify that that access group of the Operator ID lists the RuleSet and version
that
the rules in the SOAP service use.
5. (Optional) If the SOAP client does not support HTTP Basic Authentication, select
the Request tab and then enter a data mapping row for the special parameters

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy