The Generic Service Component Framework helps to simplify and automate the management of background Java services. In Oracle Applications, service component containers and their service components are run through Generic Service Management (GSM), which you can control through Oracle Applications Manager.
A service component container is an instance of a service that manages the running of the individual service components that belong to it. The container monitors the status of its components and handles control events for itself and for its components. These actions are recorded in a log for the container.
A service component is an instance of a Java program which has been defined according to the Generic Service Component Framework standards so that it can be managed through this framework. Currently, Oracle Workflow provides two service component types: Workflow Mailer and Workflow Agent Listener.
All service components have certain attributes required by the Generic Service Component Framework. Definition attributes for a component include the component name, startup mode, container type, inbound agent, outbound agent, and correlation ID. Detail attributes include the container that owns the component and the maximum idle time for an on-demand component.
A service component can have one of three startup modes.
Automatic - When a component container is started, it will automatically start its automatic service components. It will also monitor these components and restart them automatically when necessary.
On-Demand - A component container will start its on-demand service components if those components have messages waiting to be processed. For example, an on-demand notification mailer service component will be started if there are messages waiting on the WF_NOTIFICATION_OUT queue. The container will stop an on-demand service component when that component's maximum idle time has been exceeded.
Manual - You must manually start and stop the service component through Workflow Manager. The component container does not start or stop its manual service components.
In Oracle Applications, all service components use the Oracle Applications GSM container type. A component can have either an inbound agent to process inbound messages, an outbound agent to process outbound messages, or both. An Oracle Advanced Queuing (AQ) correlation ID can be assigned to a component to limit its processing to only messages marked with that correlation ID. Oracle Workflow provides two predefined containers in which you can create components, the Workflow Mailer Service and the Workflow Agent Listener Service.
Service components can also have additional configuration parameters. Some parameters are common to all components, such as component log level and the number of inbound and outbound processing threads. Other parameters may be specific to the processing that a particular type of component performs. For example, a notification mailer service component has configuration parameters to specify the inbound and outbound e-mail servers it uses.
Among both the common and the type-specific configuration paramers, some parameters can be refreshed dynamically while a service component is running. These parameters are identified in the configuration pages for the component. For example, the component log level, inbound thread count, and outbound thread count are refreshable parameters.
The control events you can perform for a service component include:
Starting a service component
Suspending a running service component, so that the threads stop processing but connections are not closed
Resuming a suspended service component
Refreshing a running service component with changed parameters
Stopping a running or suspended service component
A service component may also have additional control commands that are specific to the type of processing it performs. For example, Workflow Mailer components include a command to launch summary notifications.
You can perform these control events manually at runtime by choosing the relevant command in the Service Components page or in the Component Details page for the component. You can also schedule single or repeating control events when you are configuring a service component.
A service component can have one of the following statuses.
Not Configured - Some required configuration parameters for the component have not been completed. The component cannot be started until its configuration is complete.
Starting - The component is preparing to run.
Running - The component is running normally. You can choose to suspend processing for a component in this state, refresh the configuration parameters for the component that are dynamically refreshable, or stop the component..
Suspending - The component is preparing to suspend its processing.
Suspended - The component's thread has stopped processing, but its connections remain open. When a component is suspended, you can either resume its processing or stop it altogether.
Resuming - The component is preparing to resume processing and return to a Running status.
Stopping - The component is preparing to stop running.
Stopped - The component was stopped normally, without errors.
Stopped with Error - The component reached the maximum number of errors specified in its Max Error Count parameter and has stopped. The component container will restart an automatic component in this status, or an on-demand component in this status that has messages waiting to be processed.
System Deactivated - An automatic or on-demand component was deactivated automatically by its container because the component was stopped with an error the maximum number of times specified in the container's SVC_COMP_MAX_ERROR_COUNT service parameter. A component in this status will not be restarted automatically until the container is restarted.
User Deactivated - An automatic or on-demand component was manually stopped by a user. It will not be restarted automatically. If you want to restart it, you must do so manually.
A component with a status of Starting, Running, Suspending, Suspended, Resuming, or Stopping is considered to be active. You cannot edit the definition and detail attributes of a component while it is active; you must stop the component before you can change these attributes. However, you can edit the component's configuration parameters while it is active. If you edit any refreshable parameters, the component will be dynamically refreshed with the new parameter values.
You can manually stop a component from any status. Also, if a container stops for any reason, all of its components are stopped as well.
A diagnostic log is recorded for each component container, from the time the container starts to the time it stops. When a container is restarted, a new log is begun. You can view the log through Workflow Manager. Each log entry is marked with the container ID, and, if applicable, with the ID of the service component that generated it. You can specify the level of detail of the information you want to record for each component container. You can also specify a separate log level for some types of service components. The log levels you can select, in order from most detailed to least detailed, are as follows:
1 - Statement
2 - Procedure
3 - Event
4 - Exception
5 - Error
6 - Unexpected
The default log level for both containers and service components is Exception. This level is the recommended setting for normal usage.
The Service Components page shows the service components that are defined in your Oracle Workflow installation.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Service Components status icon
To add the information from this page to your support cart, click the Add to Support Cart button.
For each service component, the list displays the service component name, status, type, startup mode, container type, and container. Click any column heading to sort the list by that column.
To filter the service components displayed in the list, select a service component property from the Filter pull-down menu, enter a filter value in the text field, and click the Go button. You can filter by the following properties:
Service component name
Service component status
Service component type display name
Service component type internal name
To create a new service component, click the Create button.
To edit a service component definition, select the service component and click the Edit button. The steps to edit the service component definition depend on the service component type.
To view the service component container log, select the service component and click the View Log button.
To view details about a service component, either click the service component link in the Name column, or select the service component and click the View Details button. The information that is displayed depends on the service component type.
To manually control the running of a service component, select the service component, choose the command you want from the command pull-down menu, and click the Go button. You can choose the following commands:
Refresh
Resume
Start
Stop
Suspend
To manage the service instances for the container of a service component through GSM, click the container link in the Container column.
The Create Service Components page lets you choose the type of service component you want to create. This page lists the name and description of each available type. Select the type that you want and click the Create Service Component button. The steps to complete the service component definition depend on the type you select.
Currently, there are two available service component types.
Workflow Mailer - Use this type to create Workflow Mailer components to perform send and respond e-mail processing for the Notification System.
Workflow Agent Listener - Use this type to create Workflow Agent Listener components to process inbound messages on Business Event System agents.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Service Components status icon > Create
You can use Oracle Applications Manager to control service component containers as service instances in GSM.
Among other properties, a GSM service instance can have work shifts assigned to it. A work shift in turn can have service parameters associated with it. For a service instance that is a service component container, these service parameters apply to the container as a whole to determine how the container manages the components that belong to it.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Service Components status icon > container link > (B) Edit > (B) Edit Service Parameters
The Edit Service Parameters page initially displays the service parameters that can be specified for a container in the Edit Service Parameters field, together with their seeded default values. In most cases, you do not need to change these values. However, you can optionally edit these values in the Edit Service Parameters field if you choose.
You can also optionally delete any of the service parameters from the Edit Service Parameters field. In this case, for all parameters except the proxy setting parameters, the parameter values are obtained from the global settings stored in the WF_RESOURCES table. The default values in the WF_RESOURCES table are the same as the initial default values in the Edit Service Parameters page.
In the Edit Service Parameters field, the service parameter names and values should be specified separated by colons, in the following format:
<name1>=<value1>:<name2>=<value2>: . . . <nameN>=<valueN>
The following service parameters can be specified for a container:
SVC_WRITE_DIAG_TO_GSM_LOG - Specify Y if you want to write diagnostic information to the GSM log file in all cases. The default value is Y. Specify N if you want to let the FND: Debug Log Filename (AFLOG_FILENAME) profile option determine where to write the log, either to a specified file or to the database if no file is specified. For more information about FND: Debug Log profile options, please refer to the Oracle Applications System Administrator's Guide.
SVC_CONTAINER_LOOP_SLEEP - Specify the sleep time in minutes during which the container waits, after it finishes reading control messages from its GSM queue, before it checks that queue for messages again. The default sleep time is 10 seconds.
SVC_CONTAINER_READ_TIMEOUT - Specify the maximum amount of time in minutes that the container continues to block on the GSM queue after processing the last message. If another message is received before this time expires, that message is processed and the timeout period begins again. If the timeout period expires and no more messages have been received, the container stops blocking on the queue and its sleep time begins. The default timeout period is 10 seconds.
SVC_CONTAINER_LOG_LEVEL - Specify the level of detail to record for the container in its log. The default value is 4 (Exception). The valid levels are:
1 - Statement
2 - Procedure
3 - Event
4 - Exception
5 - Error
6 - Unexpected
SVC_COMP_MONITOR_LOOP_SLEEP - Specify the sleep time in seconds during which the container waits, after it starts any automatic components that need to be started, before it checks its automatic components again. The default value is 60 seconds.
SVC_COMP_MONITOR_ONDEMAND_FREQ - Specify the interval in seconds to determine how often the container checks whether its on-demand components need to be started or stopped. This activity is more costly than monitoring the automatic components and should usually be performed less frequently. The default value is 300 seconds.
SVC_COMP_MAX_ERROR_COUNT - The container-level maximum error count. If any automatic or on-demand component in the container is stopped with an error the specified number of times, the component status will be set to System Deactivated, and the container will no longer automatically restart the component. The default value is 5.
You can also optionally specify the following service parameters for proxy settings. You should set these parameters if components in this container need to use a proxy server to access web content that is outside a firewall. For example, a mailer component may need to access outside web content that is to be included in an e-mail notification. The Generic Service Component Framework uses the values you set in these service parameters to set the relevant Java System Properties.
SVC_PROXY_SET - Specify true to indicate that you want to use a proxy for your connections. The default value is NONE.
SVC_PROXY_HOST - Specify the host machine for the proxy. The default value is NONE.
SVC_PROXY_PORT - Specify the port on which the proxy is listening. The default value is NONE.
You can use the Service Instance Status page to view status details for a service component container, including the current log level for the container. The log level controls how much information is recorded in the log. Note that the log level you select here applies only to the log messages for the container. You can assign separate log levels to the individual components within the container.
Navigation: Applications Dashboard > (pull-down menu) Workflow Manager > (B) Go > Service Components status icon > container link > (B) View Status
The current log level is determined by the value of the SVC_CONTAINER_LOG_LEVEL service parameter. If no value is defined for that parameter, the log level is obtained from the default setting stored in the WF_RESOURCES table. The default container log level, which is also the recommended setting, is Exception.
You can optionally specify a different log level for the container if the container is running. To change the log level, select the level you want from the Change Log Level To pull-down menu and click the Go button. The log levels you can select, in order from most detailed to least detailed, are as follows:
1 - Statement
2 - Procedure
3 - Event
4 - Exception
5 - Error
6 - Unexpected