Supporting RESTful Access to Siebel Business Objects Dynamically

You can use the Dynamic IO feature to enable RESTful access of Business Objects without the need to create Base Integration Objects (Base IO).

Traditionally, to allow any Business Object access via REST, you had to create a new Base IO using Web Tools and migrate the same to production, which involved down-time and effort.

The Dynamic IO feature has:

• A simple process of exposing Business Object as REST API
• No overhead of creating Base Integration Objects
• No overhead of migrating Base Integration Objects from Development to Production
• No down-time, as there is no need to restart AI tomcat as there is no migration involved
• Improved access control via access configuration screen for both Base IO and Dynamic IO based
• Support for automated generation of REST user keys in tools while creating Base Integration Objects

Note: You can only specify a single Integration Object for a given Business Object when using the Administration Web Services -> Inbound REST API Access screen. Even though the Applet (REST Inbound Data Access Service List Applet) will allow you to specify more than one record, only one will be used.

This topic covers:

• Enabling/Disabling Dynamic IO

• Access Control UI

• Dynamic IO Flow

• Dynamic IO Validation

• Dynamic IO Usage Considerations

• XSD Naming Conventions

• Purging of Old XSD

Enabling/Disabling Dynamic IO

The Dynamic IO feature is controlled via the component parameter EnableDynamicIOInREST which is available in the EAI object manager. This feature is enabled by default, and the value of EnableDynamicIOInREST is set to 'true'.

• To disable the Dynamic IO feature, set the value of this parameter to 'false'.

  Example server manager command:

  change param EnableDynamicIOInREST=false for comp EAIObjmgr_enu

• To enable the Dynamic IO feature, set the value of this parameter to 'true'.

  Example server manager command:

  change param EnableDynamicIOInREST=true for comp EAIObjmgr_enu

The parameter change will take effect for all the new tasks/sessions.

Access Control UI

To see the Access Control UI, navigate to Sitemap > Administration Web Services > Inbound REST API Access.

• Once the Dynamic IO feature is enabled at component level, REST data API uses this model for access control.
• To enable access to a Business Object, the admin user should add the corresponding Business Object via the picklist and enable the flag for "Grant Access".
• All existing Base Integration Objects in the system would be migrated to the access control page automatically.
• If the Business Object enabled is not mapped to any Integration Object or if no Integration Object exists in system with Base <Business Object> pattern, then the system tries to expose the Business Object via a Dynamic Integration Object (Dynamic IO is created automatically as an XSD file).
• Open API specification for the data catalog API i.e., data/describe would list out all Business Objects enabled in the access control page.
• Open API specification for the data/Business Object/describe API would list out all possible root Business Components under Business Object if corresponding Business Object has REST access.
• With this access control model, the user can choose to use an Integration Object that does not have "Base" prefix in its name. For example, Business Object "Action" can use either Base Action or Action as Integration Object if available and configured in the access control page.

Dynamic IO Flow

This diagram shows the Dynamic IO flow for REST/data requests.

When there is a REST/data request:

1. The application checks if the Dynamic IO feature is enabled. If it is enabled, it proceeds to the next step, else it uses the existing Base IO flow.
2. It checks if access is provided to Business Object in the access control page. If the access is enabled, it proceeds to the next step, else it returns an error response.
3. If Base IO is present and active, then Base IO model is used to serve request.
4. If Base IO is not available or is inactive, then Dynamic IO/XSD model is used.

   It checks if Dynamic IO (XSD) is available for latest version of requested Business Object.

   • If present, Dynamic IO (XSD) is used, and the request is served.

   • If XSD is not available or available for an older version of BO, then then a new XSD is generated for the latest version of the Business Object being accessed.

     The newly generated Dynamic IO is stored in Siebel server's <Siebel Server>/xsd directory as a file with .xsd extension.

Dynamic IO Validation

When Dynamic IO (XSD) is created, the following validation rules are applied:

• Matching BO/BC as per request needs to be present in repository.
• Active Business Object Component under Business Object should have the corresponding active Business Component.
• Link associated with active Business Object Component should be present and valid in the repository.

Dynamic IO Usage Considerations

• Dynamic IO follows the Business Components and fields in repository.
• Any BC/field customization needed should be made and delivered to runtime repository prior to dynamic IO (XSD) generation.
• Configure the View Mode property in the root Business Component that is being exposed via the dynamic Integration Object REST feature. All child Business Components in the hierarchy inherit the root Business Component's configured View Mode. Empty View Mode information in the root Business Component can lead to data from that Business Component becoming accessible to any user (including anonymous users) without restrictions. For more information, refer to the "Viewing Business Component View Modes" topic of Siebel Security Guide.
  Note: Changing the View Mode of a Business Component may affect the data the Business Component displays in Views in the application. Thorough testing should be done to ensure that your application's functionality has not been affected by this change.
• Base IO model should be followed if any customization is needed, i.e., if custom keys are needed or if there are field/BC changes that cannot be applied to Business Component.
• The first request for a Business Object will take relatively more time when Dynamic IO(XSD) is created in a given Siebel server. Subsequent requests will be faster as the Dynamic IO is re-used.

XSD Naming Conventions

• XSD is generated and stored in the xsd folder of respective Siebel server from which the request is served.

• It has the following naming convention:

  (Root BO)_(Root BC)_(workspacename)_(workspaceversion)_(BO version)_(BC version)_(major version)_(minor version).xsd

• For main workspace requests, workspace version will always be 0.

Purging of Old XSD

• When the requested BO/BC definition is modified and a new task is started, then these new repository changes are considered and the appropriate versioned XSD is generated.
• For MAIN workspace requests old versioned XSD will be deleted prior to generation of new XSD.