Copyright © Nortel Networks Limited 2006 | 10 |
toolsets may be supported in subsequent releases once testing has been completed.
Refer to the chapter Building OPI clients for an example of generating a Java stub.
Implement interface accessing stubs
An interface must be developed that will access the stubs. The interface must support authentication on each OPI request.
If the credentials are not present, or fail validation, a SOAP fault will be sent back indicating the failure and the action will not be performed.
Refer to Error codes and messages on page 29 for a complete list of error messages.
Access stubs from the third-party application
When the interface accesses/invokes the stubs, the stub will generate a SOAP message that will be sent to the Provisioning Module on port
80.The stub is basically a translator. It takes the “user” object (whatever type of object) from the interface and converts it to a SOAP message and sends it to the Provisioning Module. The skeleton on the server with the Provisioning Module does the reverse. It takes the SOAP message and translates it back to a “user” object (whatever type of object) and sends it to the Provisioning Module’s Data Store that stores it in the database.
Authentication and authorization
Authentication and authorization of OPI requests are briefly described in the following sections:
•Authentication
•Authorization
For more information on this topic, please refer to the Provisioning Client User Guide.
Authentication
Each OPI request is authenticated using HTTP basic authentication. Each request is required to pass a username and password before gaining access to the interface. Therefore, there is no login/logout interface as the request is authenticated on each request. If the credentials are not present, or fail validation, a SOAP fault will be sent back indicating the failure and the action will not be performed. The credentials are verified against any active administrator in the MCS
