Batch Overview

Batches enable users to add, edit, and delete a group of rows to and from a staging area. From the staging area, the rows can be reviewed, validated, and then finally committed to the production tables such as the Constituent tables or the Revenue tables.

BatchTypeSpec

You can create your own custom batch types with a BatchTypeSpec in the SDK. The BatchTypeSpec references an Add Data Form to add rows to staging area tables, an Edit Data Form to edit rows in staging area tables, and a Delete Record Operation to delete rows from staging area tables. An additional Add Data Form commits and inserts each new row from the staging area tables to the production tables. In concert with this Add Data Form, an Edit Data Form can commit and edit existing rows from the staging area tables to the product table(s). The BatchTypeSpec can include event handler code to ease data entry for the end user. Event handlers can check data entry within the data entry grid. Event handlers provide ways to launch custom dialog windows/forms. The BatchTypeSpec can also include a reference to a SearchListSpec as a duplicate-record checking mechanism that scans the data within staging area tables to locate potential duplicates.

For more information, see Batch Types.

The Relationship between BatchTypeSpecs, Batch Templates, and Batches

A BatchTypeSpec defines a batch type. A batch type can define one-to-many batch templates. A batch template can define one-to-many batches. Data goes into a batch where it can be reviewed, edited, validated, checked for duplicates, reviewed in a report, and ultimately committed to the production tables.

For more information, see Configure Batches, Batch Process, and Batch Templates Are Created from Batch Types , Workflow States, and Configuring a New Batch from the Batch Template

Get Data into a Batch

Data enters the staging area tables from one of three mechanisms: data entry, import, and or a third-party system through the Web API. A user can enter data manually in a standard data entry grid provided by the batch framework. This standard data entry grid is derived from the Add Data Forms and Edit Data Forms that are used to add and edit rows into staging area tables. Additional custom dialog data entry forms can be built to complement the standard data entry grid to ease complex data entry and to provide more real estate when the batch contains many columns of data or child rows of data.

With imports, you can move data from another program into your Infinity-based application. You can create a batch to enter new records into the database or update existing records. You can create an import file with an outside application, such as Microsoft Excel. When you select the file to import, you can map each header of the file with corresponding fields in the batch.

Another way to get data into a batch from the outside is through the Web API. This technique is meant for outside, third-party applications. Such applications can utilize the general purpose AppFxWebService.asmx SOAP endpoint to access any Infinity feature including batch. An API developer can use the Web API to create a batch template from a batch type, then create a batch from a batch template, and finally manipulate data within the batch and even commit it.

For more information, see Adding Data into Batch, Adding Data into Batch via Manual Batch Entry, Import, and Web API.

Import Handlers

Import handlers allow the SDK developer to validate, alter, scrub, and enhance each row of data just before it is added (imported) into the batch staging table. For details, see Batch Import Handlers Overview.

Event Handlers

The BatchTypeSpec can include event handler code to ease data entry for the end user. Event handlers can check data entry within the data entry grid. Event handlers can also provide ways to launch custom dialog windows/forms. For details, see Batch Event Handlers Overview.

The Advent of Web Shell Impacts How You Build Event Handlers and Custom Dialog Screens

The legacy ClickOnce batch implementation is tied to Windows UI components like the Browser.Controls.EditGrid. This reliance on Windows controls means that the event handlers and custom dialog screens of a specific batch type are not portable to different presentation layers, such as the new Web Shell. Older batch types built upon the ClickOnce, Windows-based shell use WinForm technology for the custom dialog screens. These will not work in the newer Web Shell user interface which requires that a UI Model based Custom UI Model data form be used to present a custom dialog screen.

Warning: Web Shell Impact! ClickOnce batches require conversion before they can be used in Web Shell. Older batch types designed to run within the ClickOnce Smart Clientrequire that the event handler code and custom dialog screens be rewritten to be Web Shell compliant. For more information, see the Batch Event Handlers Overview.