In the first one, we will introduce the general method of receiving EDI packets, so how can you know the correctness of the received data, and availability? This requires us to carefully verify the validity of the data and import our own system.
Previous article Let's talk about the data to some "Database Table", then these tables should be designed? Is it that the table is using in the system?
According to my practice, some intermediate tables should be established to store them. This is mainly because
1. You don't know the length of the data to receive
2. The intermediate table is independent of the system, does not affect the operation of the existing system
3. Easy to expand
The simplest design is:
CREATE TABLE
COL1 ???? varchar2 (255),
COL1 ???? varchar2 (255),
COL1 ???? varchar2 (255),
COL1 ???? varchar2 (255),
COL1 ???? varchar2 (255),
......
)
This may waste space, but we have to admit that this is really what data can come in. A flexible design is, I can dynamically add deletion to modify the structure of these intermediate tables. However, we are best to set the type of field as a character type, because so, it is almost almost all data when we receive, this is also for easy expansion.
But we know that each computer system is not the same, especially in the database, the structure of the table is also a thousand words, and each field is defined and its type is also a thousand variable. So how do you import the data of the intermediate table correctly into the existing system? This requires the design of verification and import.
According to the figure above, a simple design is designed to design a middle table to the Ocean shipping order, design a middle table for the land list, and then design two verification procedures, and verify the shipping single and list of data validates, respectively. Pour the system. If you come to new (eg, the Ministry of Communications), we can use this definition in the [Amissive EDI-Verification Model (1)] to import the intermediate table without rewriting the program. Because the authentication import process is for the verification import of the intermediate table, the reception is that the field that can be written to the intermediate table is, that is, the reception of the intermediate table, the two do not necessarily contact.
However, we can see that despite the work of the front desk is free, verification and import, because it is written, there is still the possibility of expansion!
When, a new message, the Ocean United Nations boat pattern standard? We can define a middle table to receive, but for this verification of this intermediate table, and imports we still need to modify the program. Of course, if you just put this verification and import process in the background, the workload will be much smaller, but as long as there is a modification Increase, it also limits its function.
You may say that you can define a batch of rules, take these rules, verify each field of the intermediate table!
Yes, you can do this.
However, there is a problem that has restricted this extension, which is the problem of data conversion.
For example: original packet
La123'1'123 '
La123'2'100 '
We know, this message represents the number of car numbers, 1 (2) represents the serial number, 123 (100) represents the customs cargo code
So can we receive the intermediate table T_Temp???
Car number ????? serial number cargo code
La123? 1 ??????? 123
LA123? 2 ??????? 100 system
Taxation number ???? serial number cargo code cargo name
La123 1 ???????? aa ??????????? coal
La123 2 ???????? bb ???????????? iron ore sand
So from 123 to AA, from 100 to BB conversion, it is a problem with data conversion, that is, our system may make your own defined code rules, different from customs or others.
And verified, it is to verify, is it possible to correspond to our code?
You said again, you can do a conversion table, to handle this situation, yes, this is very good. But still unable to handle this new message, the Ocean United Nations boat diagram standard? Because I can't foresee all the codes that may be imported, those code need to be converted? If the rule is defined, give him a conversion flag, but the user does not know, it corresponds to the code of the table in our system (and the user is professional).
And the above, it is the reason I don't do generally verify import.
However, we should move towards the general purpose.
Made an interface, the front desk is the same, just verifying the import is different, what is the same? I can easily hill a background verification process. As long as it is judged, the user wants to verify that message, then obtain the verification intermediate table,. . . (A separate verification process).
If it comes to a United Nations import list, I just add a verification import process for the intermediate table of the import list without modifying the front desk.
