1. Application Services Interface Reference
  2. What’s New in This Release

4Administering Application Services Interfaces

Administering Application Services Interfaces

This chapter describes how to implement ASIs and how to apply them to your workflows. Some user scenarios are described for you to better understand how to administer ASIs. Topics include:

Using ASIs

Siebel ASIs are prebuilt and ready to use for integration between Siebel applications and external applications. ASIs require no change to the actual interface to be deployed and include prebuilt data maps that require no customization. You can deactivate fields and components within ASIs with no loss of their release-independence or upgradeability.

You can customize ASIs by adding new components and fields. For more information about customizing, see Customizing an Application Services Interface

Note: For other, customized interfaces (that is, not prebuilt ASIs) that you build, upgradeability across releases is not guaranteed.

The key activities when using ASIs include:

    Configuring ASIs

    Although ASIs are prebuilt, for them to be exposed to external applications, you must configure them to the requirements of the IT application environment.

    To configure an inbound data synchronization ASI

    1. Open Siebel Tools and select the integration object you want to update and deactivate the components and fields you do not require for your business service.

      Note: If an inbound ASI needs to be invoked through a workflow process, you need to define a named subsystem. See Integration Platform Technologies: Siebel Enterprise Application Integration for more information about named subsystems and how to define them.

      See Deactivating ASI Components and Fields for more information. If you only deactivated fields and no map is specified in the ASI, a data map is unnecessary. Implicit data mapping still applies.

    2. Redeploy the project into a Repository.

      The ASI is now ready to use as a business service.

    3. (Optional) If the ASI is to be made into a Web service, create a new entry in the Inbound Web Services Administration view.

    To configure an outbound ASI

    1. Open Siebel Tools and select the integration object you want to change and deactivate the components and fields you do not require for the ASI.

      See Deactivating ASI Components and Fields for more information.

      Note: Skip steps 3 through 5 of this procedure if a WSDL file exists for the internal interface. You can run the WSDL Wizard to import the necessary information. If a WSDL file does not exist, complete steps 2 through 4 of this procedure.

    2. Open the Siebel Client, choose the Administration - Web Services menu, select the Outbound Web Services screen, and define an entry for the outbound ASI.

      The port type should reference the business service created for the outbound ASI. The name of the business service and port must match the default names set on the business services definition.

    3. Open Siebel Tools, select Business User Properties, and configure the following properties:

    4. Redeploy the projects with the integration objects and business services definition into the Repository.

      Deactivating ASI Components and Fields

      By default, all fields are active for use. You can deactivate fields for your particular business needs. In general, if you are deactivating the fields of an inbound ASI, you must also deactivate the corresponding outbound ASI fields; if you deactivate the fields for an outbound ASI, you must also deactivate the inbound ASI fields.

      To deactivate a component or field

      1. Open Siebel Tools.

      2. Navigate to Integration Object, and choose the integration object you want to modify.

      3. Select the components or fields you want to deactivate.

      4. Check the Inactive column to make that component or field inactive.

      5. Deactivate the map for the component, if an explicit map exists.

      Note: Setting all fields as active slows the performance time. By deactivating fields, the amount of data sent decreases. For high-volume ASIs, deactivating fields might significantly reduce the performance and physical considerations surrounding a given integration object. Deactivate unnecessary fields to help increase performance time.

        Real Time and Asynchronous Processing with ASIs

        After an ASI request has been submitted, it executes immediately for the Siebel application or the external application in real time (synchronously). However, you can model asynchronous requests by creating two ASI methods.

        To create an asynchronous process

        1. Create an outbound ASI to provide the request arguments. See To define an inbound interface.

        2. Create an inbound ASI to accept the result from the external application. See To define an external interface.

        3. Create an explicit correlation ID in the outbound and inbound ASI to link the result to the original request.

          Batch Processing

          You can perform batch processing on ASIs by customizing the workflows to call an ASI at a specific time.

          To create a batch process

          1. Create the workflow process to call an ASI.

          2. Schedule a Server Component Request to invoke the Workflow Process Batch Manager to run the workflow process.

          See the application-specific documentation for information about customizing workflows.

            User Scenarios for ASI Administration

            The following scenario describes ASI administration. John is an integration administrator at ABC Company who must configure the prebuilt Siebel ASIs. The key activities in this scenario are:

            A back-office application is sending customer information to be synchronized from the Siebel application to a back-office system. John needs to expose an existing inbound ASI, Sync Siebel Product, to receive the customer information, which uses data synchronization services. He also needs to use an existing outbound ASI, Sync External Account, to send the updated information to another system. In addition, John must also deactivate fields in the integration objects that are not being used for these particular ASIs.

              Deactivating Fields in the Integration Object

              John needs to deactivate various fields in the integration objects for the inbound ASI, AccountReceive, and the outbound ASI, AccountSend, that are not relevant for his company’s business object. For each ASI, John:

              • Chooses the internal integration object for the specific ASI and deactivates the unnecessary fields in Siebel Tools.

              • Chooses the interface integration object for the specific ASI and deactivates the same fields he deactivated in the internal integration object. He deactivates these fields in Siebel Tools.

                Exposing an Inbound ASI

                John needs to expose the inbound ASI, AccountReceive, to receive the customer information from the back-office system. He wants the inbound ASI to be available over HTTP.

                • In the Inbound Web Services screen in the Siebel Client, he specifies the port binding information: transport, protocol, and address.

                • He publishes the WSDL file to advertise the inbound ASI and its address.

                  Specifying an ASI Implementation

                  For the outbound ASI, AccountSend, John wants to send the customer information as SOAP over HTTP. In the Outbound Web Services screen in the Siebel Client, he specifies the following for AccountSend:

                  • Transport—HTTP

                  • Protocol—SOAP

                  • File address—http://ABCcompany/sendRequests/customer