HVS32 JDBC interface (automatic polling)
Prerequisites
DGS version | 3.7.0.618 or higher |
DGS Plugins | HVS32Client, JDBC Server |
JDBC driver | latest version of JDBC driver (JDK15) for the used database |
Function description
The DataGatewayServer (DGS) selects the data records to be processed from the polling table at a configurable interval (default 1000 ms) and transmits them to the HVS32 Client for processing. The data records are selected on the basis of the control field HVS32Processed (value = 0).
By means of the control field HVS32Function, the DGS is informed which function is to be executed for the selected data record.
After the data set has been processed by the HVS32, the feedback is given. Thereby, the value HVS32Processed is set to the value 1. If an error should have occurred in the HVS32 during processing, e.g. "The route could not be determined!", the field HVS32Error is additionally set to the value 1 and the error text in HVS32ErrorText1 + HVS32ErrorText2 is reported back.
Further "subrequests / -responses" can be configured for the request and response. These SQLs are additionally executed and the data is enriched with the main request / response. For each request/response and subrequest/response, the SQL can be individually adapted and a different database source can be configured.
In addition, it is possible to configure a Fall Back, which is executed as soon as the request or response fails. For example, if an incorrect data type (alphanumeric instead of numeric values) is transmitted in the request control character or in the response. Furthermore, the case back can be used if no HVS32 clients are connected to the DGS. This is to prevent incorrect data records from being selected again and again and thus running into errors again.
Control part
The control part is used to define which action is to be carried out with the data set from the database.
Field name | Type | Max length | Decimal places | Assignment |
---|---|---|---|---|
ID | Integer | - | Unique number to identify the record (autocounter). | |
HVS32Function | Integer | - | - | The function number to be executed in HVS32 for the record. 1 = ShippingDataRequest |
HVS32Processed | Integer | - | - | Set to 1 after processing in HVS32. Records are selected based on this field. |
HVS32Error | Integer | - | - | If the record has been processed in HVS32 and an error occurred, this value is set to 1. |
HVS32ErrorText1 | String | 200 | - | Error text in case of error |
HVS32ErrorText2 | String | 200 | - | Error text in case of error |
Available HVS32 functions
Package processing (ShippingDataRequest)
The gateway function ShippingDataRequest is sent from the data gateway server in automatic polling mode to the HVS32 to generate and post a label for a package. A label is identified for all further functions such as cancellation, loading release, etc. by means of the package ID on the host side. This is transferred in the PackstueckID field and must therefore be unique within the shipping system.
Article and dangerous goods data should each be realised in a separate table with a 1:n relation to the package table. The relation of the tables can be done, for example, via the ID from the Control part.
Interface Field Description
Load/release package (LoadingShippingData)
The gateway function LoadShippingData is sent from the data gateway server in automatic polling mode to the HVS32 in order to release packages for outgoing. Only packages that have been released for exit are taken into account for the daily closing.
Interface Field Description
Update package data (UpdateVersandDaten)
The gateway function UpdateVersandDaten is sent from the data gateway server in automatic polling mode to the HVS32 to change the data of existing packages. This request is sent, for example, if the value of goods for a package is only known at a later time. A search is always made via the PackstueckID field and, if occupied, also via the TrackingNr field. With this request, however, the fields and contents to be updated are no longer checked according to the carrier's guidelines (e.g. weight limits, etc.). The upstream system must therefore ensure that the values to be updated comply with the carrier's guidelines. If this is not possible, this function cannot be used and the label must be cancelled and processed again. In addition, fields that have already been printed on a label or determined by the HVS32 dispatch system in a carrier processing (e.g. address, route, tracking no., special services, etc.) cannot be manipulated.
Interface Field Description
Cancel package (CancellationDispatchData)
The gateway function CancelShippingData is sent from the data gateway server in automatic polling mode to the HVS32 in order to cancel existing packages there that are not yet on an outgoing list. As a rule, a package is cancelled on the basis of the package ID on the host side. This is transferred in the Packing unit ID field. In addition to the host-side package ID, the tracking number can also help to identify the package, in case the host-side package ID cannot guarantee uniqueness.
Interface Field Description
Check package data (VerifyDispatchDataRequest)
The Gateway sends the DispatchDataPruefRequest to the automatic polling of the HVS32. A dispatch data request is thus simulated in the HVS32. No labels are printed and the package or label is not booked, but all other processes are identical to the shipping data request (route determination, tracking number determination, address check, etc.) This function is used to validate all shipping data in advance.
Article and dangerous goods data should each be realised in a separate table with a 1:n relation to the package table. The relation of the tables can be done, for example, via the ID from the Control part.
Interface Field Description
Anonymise package data (AnonymisiereVersandDaten)
The gateway sends the AnonymisiereVersandDaten to the automatic polling of the HVS32. In the HVS32, customer-related data is thus anonymised for the corresponding data record in accordance with the DSGVO. This anonymisation is irrevocably and finally carried out at the database level of the dispatch system. A recovery of the original data is therefore no longer possible. Log files, confirmation files, already transmitted carrier data transmission etc. are not affected by this. Only packages and consignments that have already been completed on a daily basis can be anonymised.
Schnittstellen-Feld-Beschreibung
End of day (end of day)
The gateway sends the daily closing request to the automatic polling of the HVS32. A daily closing is thus triggered in the HVS32 on the basis of the additionally transferred parameters. The daily closing consists of the items Generate_Outgoing_List and Generate Freight Guide RDT. Only packages that have been released for exit are taken into account for the daily closing. By default, all packages are released unless they have been blocked by the output scanning extension module. The feedback in the HVS32 takes place after the daily closing has been executed. No package/shipment data is available for feedback.
Interface Field Description
Examples
Please note that the following scripts are only an aid from our side. The administration of the database is the responsibility of the customer.
Field names /-lengths /-formats or table names can differ in principle, but in this case must be considered/analysed individually.