Deferred service is the service inquires the data periodically from the table(including join) has serial number defined, and apply it to the target DB. Data processing unit follow the fetch number defined on rule. If the target DB is multiple, process the whole target DB with 2PC transaction. Transaction is only supported by the unit of transaction. Transaction per item isn't supported.
Transferable data in DB batch method is as follows.
Entry | Description | Note |
---|---|---|
Data Verification Method | Data which is able to be inquired in a single query | The case that the data should be verified by multiple tables but unable to join cannot be processed. |
Processing Object Data Type | Processable Data Type Both of ascii/binary is processable | Only processable when the temporary file save mode is set to binary |
Processing Object Data Size | No limitation on the number of data which can be processed by a single job. | If the number is too large, process the transaction by the ruled processing unit(the fetch number). |
Defines JDBC Type the approach method by rule in the way JDBC supports. No transaction management required because the source is only used on data verification.
In the case of XA transaction processing, use platform provided Adapter/Datasource to approach.
(*) If it's not XA transaction, use the information registered in ISM and approach it in the same way of the source.
The database supported by source DB on ISM is as follows.
Supported JDBC types approaching source DB are as follow.
JDBC TYPE | Description | Oracle | MS-SQL | Infomix | DB2 | Others |
---|---|---|---|---|---|---|
1 | JDBC-ODBC Bridge | O(Convert it to 4) | O(Convert it to 4) | O(Convert it to 4) | O(Convert it to 4) | O(Convert it to 4) |
2 | Native-API Driver specification | O(OCI) | O(app) | |||
3 | Network-Protocol Driver | |||||
4 | Native-Protocol Driver | O(Thin) | O | O | O(net) | O |
Register SQL query to be used on data verification.
Inquiry query must satisfy following conditions..
select col1, col2, seq_no, proc_dt from source_table_#TABLE_NAME# where seq_no > #STARTSEQ# and proc_dt = #DATE# order by ser_no
If the data verification target table has to be changed by the serial number initialization condition, define the table name management class. Define the unit of the data process. Process the number of data which has inquired. Even if the process target data is more than the processing unit, process it gradually with the number of processing unit. Define the data verification period. Execute the process by the unit of data verification period. If the process target data is more than the processing unit, the verification prior is set to 1 second automatically. If the process target data is less than the processing, return to normal verification period. If there's no verification period defined, use 30 seconds as a default period.
In Source Service, defines the DB calculation which will be executed on data application on the target service. Because the data reflecting SQL query is generated automatically, define the reflecting target table name. If the data reflecting target table should be changed by the serial number initialization condition, define the table name management class.
Follow the source DB data structure definition of DB-DB batch service.
The difference between the source DB data structure definition and the batch, only a single key field has to be defined and the field must be the serial code field. The name of the key field has to be the same as the one of the column which is inquired by query.
For example,
Inquiry query)
select key_col1, key_col2, data_col1, data_col2, sequence_col from table1 where sequence_col > #STARTSEQ# order by sequence_col
Field group)
Field Number | Field Name | Key Status |
---|---|---|
0 | key_col1 | No |
1 | key_col2 | No |
2 | data_col1 | No |
3 | data_col2 | No |
4 | sequence_col | Yes |
Regardless of the key status of the table, the 5th column should be defined as a key field because the column must be used as a serial number.
Follow the target DB data structure definition of DB-DB batch service.
Follow the target DB support calculation of DB – DB batch service.
Form the interface services as the source and the target, and define the routing rule and mapping rule in the way the request is sent from the source to the target. Define the service flow from the source service to the target service by the service model. Determines whether to sequential process or parallel process in the definition of the service flow. The parallel process is only available on asynchronous batch service.
Properties | Description |
---|---|
Pattern | System Interface Pattern Set ACK transmission If it's parallel process, set the asynchronous transmission. |
Properties | Description | Accept Value |
---|---|---|
Routing Determining Method | Find the way to search the target service. | All |
Routing Input Field | When the routing determining method isn't All, define the input field. | |
Routing Pattern Value | Define the assigned input field value, pattern, or the result of the calculation. Send the request to the target service which has the same value set. | |
Service Mapping | Define the conversion rule between the source service and the target service. | Mapping Rule. |
Error Mapping | Defines the conversion rule when the error response returned from the target service. | |
Target Service | Define the target service to send the request according to the routing pattern value. | Target Service |
Properties | Description |
---|---|
Pattern | System Interface Pattern Set ACK transmission. If it's parallel process, set the asynchronous transmission. |
Integration Service defines the source and target system on service model result, and the rules of other Batch Service on run. Other information besides processing flow for Batch Integration Service is as follows.
Properties | Description | Default Value |
---|---|---|
2PC Status | If it's not 2PC transaction, the transaction between the source interface process and the target interface process is seperated. | Yes |
Message Verification Status | Analyze the input message per field and apply the verification condition to verify. If there's no verification condition, verify the length and type. | No |
Post-process | The process has to be handled after DB data transmission. | None |
Rollback type | The whole – If even a single case fails, rollback the whole. Failed data – progress it continuously even is there's a failed data (*) The range of the whole is the data by the 1 time inquiry number of data | The whole |
Inquiry Period | Deferred Service Execution Period. 60 seconds as default | 60 |
Maximum Serial Number | The maximum serial number as the condition to initialize the serial number. (*)Used when the condition of the serial number initialization is the maximum serial number. | 1000000000 |
1 time Inquiry Number | The maximum inquiry number by the 1 time of deferred service execution (*) 1000 as default (*) If the number of inquired data is the same as the 1time inquiry number, consider it has more data and set the inquiry period to 1 second automatically. |
1000 |
Serial number initialization condition | Serial number initialization condition setting | Not in use(increases unconditionally) |
Finishing job field name | Set when the serial number is initialized by the finishing job field value. | None |
Finishing job field name | Set when the serial number is initialized by the finishing job field value. | None |
Final value transfer status | Whether to send the final value on the initialization by the maximum serial number. (*)Set not to send only when the maximum serial number isn't the data but has the meaning as the final. | Do not transfer |
Automatic generation of serial number | Whether to generate the serial number of the inquiry target table automatically. of the source system. (*)There must be additional field to be used as the serial number, date information on automatic generation. | Not generated |
Serial Number Field | Serial Number Field | None |
Date Field | System Date Field – yyyyMMdd form | None |
Final value verification class | In the case of the maximum serial number, use it when the final value doesn't exist on the verification target table but on the extra table. | None |
The data inquired on the source DB is saved as file on the target system. How to process it is the same as the DB-DB deferred service. However, the generation rule of the file data must be defined. If the file which has the same name is generated in saving file on the target system, it overwrites on the previous file, so it always have to be saved as new file or the type of file is available for subsequent writing. In processing of the subsequent writing, the same file can be bigger and bigger indefinitely so it should include at least the date of written or the time information to prevent this. The target filename is geneated throught the fileneame management class. To look up the way to use the file management class, refer to the target file management class(ISM:BatchFile#Target Filename Management Class) of the batch file service
It is the same as DB-DB deferred service.
It is the same as DB-DB deferred service.
It is the same as the source service definition method of DB-DB deferred service.
It is the same as the source processing rule of DB-DB deferred service.
Defines the directory and filename to store the data in the target service. Define the filename management class to generate the filename differently for every process.
Follow the source DB data structure definition of DB-DB deferred service.
Follow the target file data structure definition of the file batch service.
Follow the result reflecting data structure definition of DB-DB deferred service.
Follow the target file process definition of file batch service.
The configured contents is the same as the DB-DB deferred service.
The configured contents is the same as DB-DB deferred service.