Architecture

Unknown macro: {scrollbar}

The architecture is designed so that each component only needs to do the smallest amount of work necessary to perform its job. A component does not need to know anything about schedulers, workflow engines, audit logs, or other components.

Control Flow

BI Components are executed as a result of someone or something requesting the Pentaho Solution Engine to execute an action sequence. Action sequences can be executed by users, schedulers, web services, workflow engines and API calls. In all cases the caller can provide parameters to the action sequence. The action sequence can, in addition to parameters from the request, define parameters that are fulfilled from other places such as a session. This section and chart describes the order of events as an action sequence is executed.

Start. A call is made to an object in the services layer requesting execution of an action sequence. These objects use a request handler object that implements org.pentaho.core.services.IActionRequestHandler, create an instance of org.pentaho.solution.SolutionEngine, or use the helper methods in org.pentaho.core.solution.SolutionHelper. In each of these cases, parameters providers are passed to the solution engine. The request handlers and solution helper create an instance of the SolutionEngine and call its 'execute' method specifying the path and name of the action sequence to be executed and the parameter provider.
Examples of objects that do this are:
- Servlet: org.pentaho.ui.servlet.ViewAction
- UI Component: org.pentaho.ui.component.ActionComponent
- Web Service: org.pentaho.ui.servlet.HttpWebService
- Scheduler: org.pentaho.plugin.quartz.QuartzExecute
- API: org.pentaho.core.solution.SolutionHelper
The Solution Engine's 'execute' method:
- Checks that both the action sequence path and name have been provided
- Creates an instance of an IRuntimeElement and an IRuntimeContext. The details of the creation of this instance are added to the audit log along with its association with the caller's session. The Runtime Element stores the state of the action sequence if the process is long running, and the Runtime Context will handle the execution of the components.
- Calls the Solution Repository to load the action sequence. If the action sequence cannot be found, an error is returned to the caller and the failure is audited.
- Calls the Runtime Context's 'validateSequence' method.
The Runtime Context's 'validateSequence' method:
- Sets the logging level of the action sequence to the desired level (can be specified by the original caller).
- Creates an instance of a component for each action defined in the action sequence. If the sequence includes two actions which use the EmailComponent, two instances of the component will be created. The same instance of the component will not be used for both actions. The Runtime Context needs BI Components to have a default constructor that accepts no parameters.
- Provides each component with various objects such as the caller's session, the requested logging level, and the Runtime Context.
- Calls each component's 'validate' method.
The component's 'validate' method:
- Calls its own 'validateSystemSettings' method to validate any system-wide settings it needs.
- Calls its own 'validateAction' method to validate that the inputs, resources, and outputs available to it (as defined in the action sequence) are sufficient for it to execute.
  If either of these validations fail for any component, the execution of the action sequence is terminated and the status is returned to the caller.
The Solution Engine's 'execute' method calls the Runtime Context's 'executeSequence' method.
The Runtime Context's 'executeSequence' method:
Steps and loops through the action definitions in the action sequence calling its 'executeAction' method for each action defined.
The Runtime Context's 'executeAction' method:
- Audits the start of component execution.
- Resolves the parameters to be made available to the component as defined in the action sequence, e.g. from the request parameter provider from the session parameter provider or from the outputs of other components.
- Calls the component's 'init' method.
The component's 'init' method performs any initialization steps it needs.
The Runtime Context's 'executeAction' method calls its 'executeComponent' method.
The Runtime Context's 'executeComponent' method calls the components 'execute' method.
The component's 'execute' method performs the steps it needs to complete its function.
The Runtime Context's 'executeComponent' method calls the components 'done method.
The component's 'done' method performs any clean-up steps it needs.
The Runtime Context's 'executeAction' method audits the end of the component execution.
The Solution Engine's 'execute' method
- Audits the end of the action sequence execution
- Returns the Runtime Context to the caller.
End. The caller can use the Runtime Context to
- Get the final status of the execution
- Get the output objects of the action sequence
- Get the debug or error messages

Solution Engine	Runtime Context	BI Component
1. start The request handlers and solution helper create an instance of the SolutionEngine and call it's 'execute' method specifying the path and name of the action sequence to be executed and the parameter provider.	1. start The request handlers and solution helper create an instance of the SolutionEngine and call it's 'execute' method specifying the path and name of the action sequence to be executed and the parameter provider.	1. start The request handlers and solution helper create an instance of the SolutionEngine and call it's 'execute' method specifying the path and name of the action sequence to be executed and the parameter provider.
2. execute() Checks that an action sequence path and name have been provided Creates an instance of an IRuntimeElement and an IRuntimeContext. Calls the Solution Repository to load the action sequence. Calls the Runtime Context's 'validateSequence' method.
	3. validateSequence() Sets the logging level. Creates an instances components. Provides each component with various system objects it needs. Calls each component's 'validate' method.
		4. validate() Calls its 'validateSystemSettings' method to validate any system-wide settings it needs. Calls its 'validateAction' method to validate that the inputs, resources, and outputs.
5. execute() Calls the Runtime Context's 'executeSequence' method.
	6. executeSequence() Steps and loops through the action definitions in the action sequence calling 'executeAction'
	7. executeAction() Audits the start of a component execution. Resolves the parameters Calls the component's 'init' method.
		8. init() Method performs any initialization steps it needs to.
	9. executeAction() Calls 'executeComponent'.
	10. executeComponent() Calls the component's 'execute' method.
		11. execute() Performs the steps it needs to complete its function.
	12. executeComponent() Calls the components 'done method.
		13. done() Performs any clean-up steps it needs to.
	14. executeAction() Audits the end of the component execution.
15. execute() Audits the end of the action sequence execution. Returns the Runtime Context to the caller.
16. end The caller can use the Runtime Context to Get the final status of the execution Get the output objects of the action sequence Get the debug or error messages

As you can see from the diagram there are only a few levels of method calls between the 'execute' of the Solution Engine and the 'execute' of the components. This lightweight framework is very powerful but does not impose a heavy processing load on the system.

BI Components are not cached between calls to the Solution Engine and must be thread safe.

If a BI Component needs to create any global resources or call any static initialization methods, a class that implements IPentahoSystemListener should be written and registered in 'system/pentaho.xml'. See org.pentaho.plugin.kettle.KettleSystemListener and org.pentaho.plugin.jfreereport.JFreeReportSystemListener for examples.

Each BI Component needs to know the parameters that it needs to perform its duties. For example a scripting component needs to be provided the script to be executed whereas a report component needs to be provided the report template and the data to be included.