Understanding Creating Component Interface-Based Services

PeopleSoft Integration Broker enables you to take an existing component interface and create a service that can be used to invoke the component interface. Further, it creates service operations, including request messages and response messages (if appropriate). The system creates an inbound any-to-local routing for the service operation version, as well as handlers for each method you choose to include in the service.

All service operations you generate from component interfaces are synchronous service operations.

This section highlight the naming conventions that the PeopleSoft system uses when it creates services and services-related data based on component interfaces.

When it creates a web service from a component interface, the PeopleSoft system adds a CI_ prefix to the component interface name. So if the component interface name is MYCI, the service name the system creates is CI_MYCI

The following table highlights naming conventions the PeopleSoft systems applies to other services data based on the method with which you are working:

Component Interface Method

Service Operation Name

Message Name

Component Interface Handler

Request Message Shape

Response Message Shape

Create

<service_name>_C

Mxxxxxx

ONREQUESTHDLR

CI Buffer

Key

Find

<service_name>_F

Mxxxxxx

ONREQUESTHDLR

Get Keys

CI Buffer

Get

<service_name>_G

Mxxxxxx

ONREQUESTHDLR

Find Keys

Key Collection

Update

<service_name>_UP

Mxxxxxx

ONREQUESTHDLR

CI Buffer

Notification

Updatedata

<service_name>_UD

Mxxxxxx

ONREQUESTHDLR

CI Buffer

Notification

User-defined

<service_name>_<method_name>

Mxxxxxx

ONREQUESTHDLR

CI Buffer

Method Return Type

The naming convention used for message names, Mxxxxxx, is the letter M followed by a random six-digit number, as denoted by the x's. An example of a message name is M548902.

Note: The maximum number of characters for a service operation name is 30. If using a user-defined method name yields a greater result, the name is used is <service_name>_Mxxx, where xxx is a three-digit random number. An example of such a name is CI_USERCI_M101023.

This section discusses restrictions related to using user-defined methods when exposing component interfaces as services.

User-Defined Method Actions

User-defined methods which are executed with the Create action should not be exposed as web services.

Specifying Method Parameters and Parameter Names

All user defined methods that will be accessed via the service interface must have a doc string.

The doc string contains:

  1. The keyword GET. .

  2. An ordered list of parameter names corresponding to the method's parameters.

The following example shows the format of the doc string:

Function simpleFunction(&sParm As string, &dParm As date, 
                        &nParm As number, &bParm As boolean) 
                        Returns string
   Doc "GET, StringParm, DateParm, NumParm , BoolParm"
   
   Local string &aString = &sParm;
   &aString = &aString | " -- " | &dParm;
   &aString = &aString | " -- " | &nParm;
   &aString = &aString | " -- " | &bParm;
   Return &aString;
   
End-Function;

The contents of the doc string are used when the function is invoked. For example, if GET is specified, then the GET keys are set, and GET is called on the component interface before the used-defined method is invoked.

The list of parameters are used at runtime to match the data in the input message with the method's parameters. This is an ordered list; if the parameter list in the doc string and the method parameters don't match, then the method may not work correctly. The names in the doc parameter list will be the names visible in any WSDL created for the service.

Method parameters and return values must be of a primitive type, such as a string, date or number. Object parameters or return values are not supported.

If a user modifies or deletes a component interface in PeopleSoft Application Designer, when the user saves the changes, PeopleSoft Integration Broker checks if a service exists for the component interface. If a service exists, and the component structure/properties have changed in the component interface, a warning message appears stating that a service exists for the component interface.

If the component interface structure changes, a status of Does not match appears in the CI-Based Services Review Status grid, and the operation appears as active in the Service Operations component.