Batch service generally processes a large amount of data. If the large data is transferred from a DB to another DB, the amount of transmission can be counted up to millions or billions. This large amount of data cannot be processed in a single transaction unit, so the batch service divides the target data into a certain fixed size of data.
To reproduce the batch service, requests with the very first requested batch process ID. If the batch process ID is the proses which an error has occurred, ISM reprocess the job right after the point of error occurence. Failed job can be reprocessed by the administrator through web console.
If there is a job to be processed before or after the Batch Service, it can be registered to pre/post task of the Batch Service so that they can be executed before or after the Batch Process. For instance, if a stored file has to be applied to the source system's DB after the file transmission on the Batch Service is completed, the post process which runs the script uploading file to DB can be executed. If the pre task fails, the main process of Batch Service won't run. If the main Batch Service Service doesn't completed normally, the Post task won't run. Even if the Post Process fails, the main process of the main Batch Service won't rollback.
Batch service defines the required parameter as follows.
| Parameter type | description | note |
|---|---|---|
| source file name | target file name | |
| source file name | filename to be saved in target system | |
| query parameter | The parameter to be replaced on Query when DB batch is inquiring the data | Saves as "parameter_name=parameter_value." If the parameter is plural, the delimiter of each parameter is "&" |
| Previous process parameter | The parameter to replace the data to be used on previous process | the same way to define the query parameter. |
| Post process parameter | The parameter to replace the data to be used on post parameter | the same way to define the query parameter. |
Follow the instruction of batch agent installation to see how to define the parameter. The users can previous process/post process parameter can be added/deleted through by Custom process including custom handler. Use ISM based development guide and JobUtil class to see how to add/delete the parameter.
Most of File – File Batch Service conduct the function of sending the file without file data conversion. In addition, the transfer also happens occationally by the administrator for its business nature. In the case the user completed a specific operation and request to send the file to him that instant, the transmission of file is recognized not as a usual Batch Service but the part of online service. For the reason, maximum performance is required on File Batch Service which will still fall short of online service. For that, the function of direct file transfer is provided in the condition of the simple file transfer service with no need of conversion.
When ISM received the file transfer request, the file is transferred between the source and target systems. This is used when the FTP access to the source and target is restricted from external system and it's only available on ISM.
When ISM receives the file transfer request, transfer the file to the agent directly. The agent transfer the file in stream relay between the source and target system just the same as the ISM direct transfer.
Multiple timeout settings are used on batch service. Each timeout as follows.
Service Process Timeout is the timeout period which send the process request to the source or target interface process and wait the response. If no response is made within the period of time, the batch manager consider and process it as a failure of the job. The timeout period is fixed to 2 hours.
The timeout is the period of waiting the inquired contents to be generated. The batch service starts from DB is suspended as much as the time spent by the amount of the data verification. Because the batch service sending converted file is only able to execute the latter conversion process, data verification(fetching file) and data application(converting and transferring) progresses sequentially. Since the DB batch service verify the data and save it partitively, new verification result files are generated even before all the data verification completed. Therefore, data application process is able to be processed while the data verification. To execute the data verification and application at the same time, the data verification process is running on background. To process the data application process, the batch manager check whether the file is generated as the result of the verification or not. On inquiry, if the file isn't generated within the timeout period, the batch manager consider and process it as a failure. The timeout is applied to each of the partitioned files. For example, if the data Fetch count is 1000 and the data count has to be sent is 10000, 10 files are generated as the result of the inquiry. Batch manager waits for each 10 files within each timeout period. The timeout period is defined as the batch service's timeout on integration service definition. If it isn't defined, 60 seconds is set to the default timeout.
FTP Connection Timeout is the timeout which FTP connection couldn't be available for the error of the opponent's FTP server's failure. Commonly, if FTP isn't on running or the port information is invalid, the connection is refused, but if it's running abnormally, the user might have to be suspended in the middle of connecting with the firewall. Through this the batch service can be suspended unprocessed, to prevent this timeout is used on connecting. The period of time is set to the timeout value of the source and target on integration service definition. If it isn't defined, it's set to default value, 30 seconds, for connecting timeout.
In DB data reflecting batch service, a duplication error could occur according to preset key value of the target DB, and the batch service could fail as a following consequence. In the normal condition, precise data must be applied to the target DB without any duplicated date. However, a certain error data could effect the whole service by not reflecting the whole data. Because the correction of the pertinent error data takes too much of physical time and the whole data which should be applied within the time to the target DB, the other services using this data could occur serial failures or errors. It is functionally normal, but it can be a risk factor in the aspect of service management. It is hardly possible to ignore every single error from the batch service, there's an option available to ignore some duplicated data which takes little effects from the error.
<batch> <db ignoredup="true"/> </batch>
If the value of ignoredup is true, ignore any duplication error.