TDABusinessProcessor

From RemObjects Software

This is a Data Abstract Architecture entry
Feel free to add your notes to this topic below.

Overview

Business Processors provide the core logic for processing changes from client applications and applying them to the back-end database.

Business Processor functionality tightly integrates with the default data service implementations provided by Data Abstract (TDataAbstractService for new v4.0 style servers, and TDARemoteService for the legacy v3.0 server interface), allowing the majority of middle-tier server applications to function without any manual processing code.

Furthermore, the data service classes provide the ability to automatically and internally instantiate business processors as needed, requiring you to drop and manually configure TDABusinessProcessor components only if you want to override the default behavior.

File

uDABusinessProcessor

Declaration

TDABusinessProcessor = class(TScriptableComponent, IDASQLGenerator);

Hierarchy

TScriptableComponent
- TDABusinessProcessor

Properties

Property	Type	Description
BusinessRulesID	String
CurrentChange	TDADeltaChange	This is an individual changed record currently being processed.
CurrentDelta	TDADelta	CurrentDelta is the set of changes currently to be transmitted between client and server.
DeleteCommandName	String	This command will be used to apply DELETE changes for the data table back to the server. This property only needs to be assigned if your schema provides a special command for processing DELETE changes (which could be an SQL DELETE statement or a stored procedure). To make the business processor use this command, remove poAutoGenerateDelete in the ProcessorOptions; if poAutoGenerateDelete is specified, the Business Processor will automatically generate the necessary SQL code to perform the DELETE on the database.
InsertCommandName	String	This command will be used to apply INSERT changes for the data table back to the server. This property only needs to be assigned if your schema provides a special command for processing INSERT changes (which could be an SQL INSERT statement or a stored procedure). To make the business processor use this command, remove poAutoGenerateInsert in the ProcessorOptions; if poAutoGenerateInsert is specified, the Business Processor will automatically generate the necessary SQL code to perform the INSERT on the database.
ProcessorOptions	TDAProcessorOptions	Configures various options for the behavior of the business processor. Available options include: Generate automatic INSERT statements instead of using the InsertCommandName. Generate automatic UPDATE statements instead of using the UpdateCommandName. Generate automatic DELETE statements instead of using the DeleteCommandName. Generate automatic SELECT statements instead of using the RefreshDatasetName. Prepare commands against the back-end database for faster execution. See IDASQLCommand.Prepared for details. Disable the "no rows were affected by this update" error message.
ReferencedDataset	String	The dataset (data table) to which this business processor refers. Every business processor is configured to handle deltas for one specific data table, and this property will be used to determine which table is handled by this processor.
RefreshDatasetName	String	Sets the name of the datatset (data table) that will be used to fetch refresh data from the server. This property only needs to be assigned if your schema provides a special dataset for refreshing data from the server (which could be an SQL SELECT statement or a stored procedure). To make the business processor use this dataset, remove poAutoGenerateRefreshDataset in the ProcessorOptions; if poAutoGenerateRefreshDataset is specified, the Business Processor will automatically generate the necessary SQL code to perform the SELECT on the database.
Schema	TDASchema	References the TDASchema that the business processor will be working on. Most commonly, this is the ServiceSchema of the data service. All the data tables and commands referenced from InsertCommandName, UpdateCommandName, DeleteCommandName, RefreshDatasetName and ReferencedDataset must be defined in this schema.
UpdateCommandName	String	This command will be used to apply UPDATE changes for the data table back to the server. This property only needs to be assigned if your schema provides a special command for processing UPDATE changes (which could be an SQL UPDATE statement or a stored procedure). To make the business processor use this command, remove poAutoGenerateUpdate in the ProcessorOptions; if poAutoGenerateUpdate is specified, the Business Processor will automatically generate the necessary SQL code to perform the UPDATE on the database.
UpdateMode	TDAUpdateMode	Defines how rows for UPDATEs and DELETEs will be located. Available options are: Only the fields from the primary key (PK) of the data table will be used to locate records for UPDATEs and DELETEs. All fields defined for the data table will be used to locate records for UPDATEs and DELETEs. The fields from the primary key (PK) of the data table plus those listed in the business processor's UserUpdateFields property will be used to locate records for UPDATEs and DELETEs. Only the fields listed in the business processor's UserUpdateFields property will be used to locate records for UPDATEs and DELETEs.
UserUpdateFields	TStrings	Contains the list of fields to be used to locate rows for updating and deleting, if the UpdateMode is set to updWhereKeyAndUserDefined or updWhereUserDefined.

Events

Event	Description
OnAfterProcessChange	Fires right after the business processor is finished processing an individual change received from the client. Use this event to inspect or log the result of the change, and to determine if the individual change can be removed from the delta as having been fully processed, or not.
OnAfterProcessDelta	Fires right after the business processor is finished processing a delta received from the client. You can use this event to inspect (or modify) any resulting delta that was generated and will be sent back to the client.
OnBeforeProcessChange	Fires just before the business processor starts processing an individual change received from the client. Use this event to inspect or make modifications to the change before it will be applied, or to prevent the change from being applied at all by setting the ProcessChange parameter to false.
OnBeforeProcessDelta	Fires just before the business processor starts processing a delta received from the client.
OnGenerateSQL	Fires after the business processor has generated code for applying an update. You can use the SQL parameter passed to this event to inspect, log or even modify the SQL before it will be applied. Note that this event will not fire for every individual change that is being processed; for each round of updates, the business processor will only generate each type of SQL statement (INSERT, UPDATE, DELETE and refresh SELECT) once. Therefore, you should not use this event to make change-specific modifications to the SQL code.
OnProcessChange	Fires as the business processor processes an individual change. Use this event to inspect or log the change being processed, including the actual command and it's parameters that will be run on the dataset. You can also use this event to make last adjustments to the command or its parameters, if needed, but modifications to the change itself will have no effect, as the command has already been fully initialized.
OnProcessError	Fires if an error occurred while applying an individual change to the back-end database.
OnRefreshDeltaChange	Fires as the business processor executes the data refresh for an individual change. Use this event to inspect or log the refresh, including the actual SQL and dataset parameters . You can also use this event to make last adjustments to the dataset SQL or its parameters.

TDABusinessProcessor

From RemObjects Software

Overview

File

Declaration

Hierarchy

Properties

Events

See Also

Views

Personal tools

Navigation

products

special

Search

Toolbox