Understanding Configuring PeopleSoft Integration Broker for Handling Services

This section provides an overview of several of the service configuration properties that you must set to use services with PeopleSoft Integration Broker.

Namespaces provide a method for qualifying element and attribute names that are used in XML documents and are identified by Uniform Resource Identifier (URI) references.

To provide PeopleSoft services you must specify a service namespace and a schema namespace.

The Service Configuration page enables you to define default values for these namespaces. You may redefine the default values for specific objects when needed:

You can redefine the service namespace for each PeopleSoft service definition
You can modify namespaces in each nonrowset-based message's schema.

You cannot change the direction of a REST service (provider or consumer) once defined in the PeopleSoft system. However, with respect to a non-REST service, a simple change to the routing definition can change its direction from consumer to provider and vice versa.

As a result it’s good practice to set the default values for the service namespace and schema namespace, regardless of whether your system is a service provider or a service consumer of REST or non-REST services.

When configuring the PeopleSoft system for services, you set target locations for web services and for REST services, using the Target Locations page.

For web services, target locations are URLs that PeopleSoft Integration Broker uses to build and validate XML message schemas, export WSDL documents, and as the SOAP endpoint. For REST services, target locations are URLS that PeopleSoft Integration Broker uses to export WADL documents and as the REST endpoint.

PeopleSoft Integration Broker enables you to define an unsecured target location and a secured target location URL for each type of service, and provides separate fields for doing so.

In general, the URL you specify as a target location should be an unsecured URL.

Note: XML schema validation will fail if you enter a secured URL in the Target Location field.

If you need to use a secure URL for a SOAP or REST endpoint, you may do. Any secure URL you enter overrides any unsecured URL entered.

In addition, you can override the (unsecured) target location URL for exporting WSDL and WADL documents on a case–by–case basis. The Provide Web Service wizard features a Use Secure Target Location box in Step 2 – Select Service Operations of the Wizard. If you select the box, the system exports the WSDL or WADL document to the URL specified in the secure target location defined on the Target Locations page. The override is in effect only for that particular export of WSDL or WADL. If you need to generate WSDL or WADL again for the service, the system defaults back to using the (unsecured) target location URL, unless you again check the Use Secure Target Location box in the wizard to override the URL to use the secure target location.

To use services with PeopleSoft Integration Broker, you must specify web service and REST service target locations. Specifying a secure target location for either of these is optional..

The Services Configuration page contains a Service System Status drop-down list box that enables you to restrict rename, delete, and other administrative actions that users can perform on services, service operations, messages, and other integration metadata.

You can select one of two values from the drop-down list box: Production or Development.

The following table describes the impact of each of these setting on managing integration metadata:

Object	Action	Production Mode	Development Mode
Messages	Rename	You cannot rename a message that is associated to a service that has WSDL or WADL provided. You must first delete the WSDL or WADL documents before you can rename the message.	An alert message displays indicating that WSDL or WADL documents have been provided for the service to which the message is associated, but you may continue with the action and rename the message.
Messages	Delete	You cannot delete a message that is associated to a service that has WSDL or WADL provided. You must first delete the WSDL or WADL documents before you can delete the message.	An alert message displays indicating that WSDL or WADL documents have been provided for the service to which the message is associated, but you may continue with the action and delete the message.
Message Schemas	Delete	You cannot delete a message schema that is associated to a service that has WSDL or WADL provided. You must first delete any WSDL or WADL documents before you can rename the schema.	An alert message displays indicating that WSDL or WADL documents have been provided for the service to which the message schema is associated, but you may continue with the action and rename the schema
Queues	Rename	The Service System Status has no impact on renaming queue definitions. However, you cannot rename a queue if it is referenced in a service operation or if it is referenced in the runtime tables.	The information that applies to renaming queues in production mode also applies to renaming queues in development mode.
Queues	Delete	The Service System Status has no impact on deleting queue definitions. However, you cannot delete a queue if it is referenced in a service operations or if it is referenced in a runtime table.	The information that applies to deleting queues in production mode also applies to deleting queues in development mode.
Routings	Rename	The Service System Status has no impact on renaming routing definitions.	The information that applies to renaming routing definitions in production mode also applies to renaming routings in development mode.
Routings	Delete	You cannot delete an any-to-local routing definition that is tied to a service that has WSDL or WADL provided. You must first delete the WSDL or WADL document from the service before deleting the routing definition.	An alert message displays indicating that WSDL or WADL documents have been provided for the service to which the routing is associated, but you may continue with the action and delete the routing definition.
Service	Rename	You cannot rename services that have had WSDL or WADL documents provided. The WSDL or WADL documents must be deleted before you can rename a service.	An alert message displays indicating that WSDL or WADL documents have been provided for the service, but you can continue with the action and rename the service.
Service	Delete	The Service System Status has no impact on deleting services. However, you cannot delete any service that is referenced by a service operation.	The information that applies to deleting services in production mode also applies to deleting services in development mode.
Service Operation	Rename	You cannot rename service operations that are associated to services that have WSDL or WADL provided. You must delete the WSDL or WADL before you can rename the service operation.	An alert message displays indicating that WSDL or WADL documents have been provided for the associated service, but you may continue with the action and rename the service operation.
Service Operation	Delete	You cannot delete service operations that are associated to services that have WSDL or WADL provided. You must delete the WSDL or WADL document before you can delete the service operation. If you delete the default service operation version, all versions of the service operation are deleted. You cannot delete a service operation that is referenced in the runtime tables.	An alert message displays indicating that WSDL or WADL documents have been provided for the associated service, but you may continue with the action and delete the service operation. You cannot delete a service operation that is referenced in the runtime tables.
Service Operation	Change Service	You cannot change a service operation that is associated to a service that has WSDL or WADL provided. You must first delete the WSDL or WADL documents before you can modify the setting. The new service to which you associate an operation may have had WSDL or WADL generated. However, if you want the WSDL or WADL from the newly associated service operation to be included in the WSDL or WADL document, you must export the service again.	An alert message displays indicating that WSDL or WADL documents have been provided for the associated service, but you may continue with the action and change the service associated with the service operation. The new service to which you associate an operation may have had WSDL or WADL generated. However, if you want the WSDL or WADL from the newly associated service operation to be included in the WSDL or WADL document, you must export the service again.