Use WebService to integrate with Oracle EBS (below)

The first section briefly introduces the ideas.ArticleLet's talk about the implementation.

Link

II,Architecture

The system is generally divided into two parts: an EBS and an interface system of an enterprise, and a third-party vendor self-built system.

The enterprise headquarters system consists of two parts: Ws Interface System and original EBS system.

The EBS part can be divided into two parts: formal table and interface table.

The overall requirements are technically divided into two categories:

Ø read-only EBS

WS directly reads data from the EBS production table or interface table. Because the write operation is not involved, you only need to know the database structure to obtain the required data;

Ø read/write EBS (interaction required)

This part of work is complicated and requires EBS write operations. Due to the complexity of EBS, the content needs to be written to the interface table, and the standard request is used to process the import from the interface table to the formal table.

When data is imported to a formal table, verification may fail. In this case, standard requests generally record error information in the interface table or other places, if a third party needs this information, you can call the interface table to draw a conclusion. In short, the interaction between a third party and EBS can be obtained by combining the two methods, but the interaction efficiency may be relatively slow, that is, there is a certain latency in the middle.

The so-called standard requests refer to some of the features provided by EBS. As to what standard requests are provided by EBS, You need to refer to relevant documents of EBS, no one can provide it.

In terms of technical architecture, the WebService interface is developed in Visual Studio 2008, becauseProgramLanguage independence. Therefore, as long as standard interface rules are used, they can be used by multiple third-party vendors.

Iii. WebServiceInterface implementation

WS servers are implemented using windows2008 + IIS. ws is used to communicate and interact with EBS by third-party vendors to ensure the systems of third-party vendors (whether at the headquarters or in overseas IDCs) can communicate with EBS smoothly. This part of interface implementation is described in multiple parts:

ØSecure Communication

When a third party communicates with WS, the communication security needs to be considered. ws itself will work in https mode.

Because domain verification cannot be used by all third-party systems, we need to consider more common ws verification methods for data transmission.

When a new third-party vendor is added, the system will assign them a password string (32 bytes), which is unique to each vendor (system, it will not be reported to different vendors. Each time the data is sent, the password string will be sent together to determine the validity of the uploaded data. Likewise, this method is also used for data downloading.

ØFlexibility

The Ws design principle should be to encapsulate database tables as much as possible, so that the third party can work normally without having to know too much about the EBS table structure. However, we also need to consider the WS scalability, therefore, too many interface functions cannot be implemented. Schema should be used to describe them as much as possible. Each schema corresponds to a specific business and operation, and schema expansion is quite flexible, with the development of business and the continuous improvement and development of new third-party vendors, a standard EBS interface Schema Library can be formed and corresponding descriptions can be formed. Appropriate schemas can be selected for use.

So far, we have explained only two aspects of implementation, security and flexibility. In the next phase, we will describe several other aspects.

ØRead data

You can use a special interface function to read data. There is only one function that can be reloaded several times to achieve different needs. In more cases, the schema parameter is used to differentiate the operation type, the returned type is an XML file, and the third party will know how to disassemble the returned XML file. XML can be a single table or a multi-Table Record set. The specific return format is completely specified by the schema. Before returning, consider the transmission efficiency, the data to be returned must be compressed and then returned in the form of a binary array.

2. function prototype

Public byte [] getdata (string schemaname, string whereclause, string password) // retrieve the record set of the specified condition

2. Parameters

Schemaname

The name of the specified mode. The usage of the mode and mode will be described later.

Based on the specified mode, the system will find the corresponding table and return the required fields

Whereclause

It returns records based on a query condition, which can implement complicated query functions. The returned record set follows the specified schema.

Password

A hash string allocated by the system to a third-party manufacturer (system). As a unique identifier, after receiving a message, the server checks the validity of the password string, if this string does not exist in the system, no operation is allowed.

Detailed descriptions and usage of the password string are described later.

2. Return Value

The returned values are all byte arrays and are directly returned without XML. This allows more processing before transmission, such as compression and encryption. encryption is not included in this design, standard CompressionAlgorithm.

After receiving the byte array, the third party uses the standard compression algorithm to unbind it and restore it to an XML file.

On a third-party client, the corresponding schema will be used to parse the XML. The specific schema is determined by the client and has nothing to do with the server. How to Use the schema after information is disassembled, it is also controlled by the client.

If the operation fails, the returned error will also be returned in the byte array format. Therefore, after receiving the error, the client must first check whether the operation is successful. If it is confirmed that the operation has not failed, then check the specific returned content.

ØWrite function

A write action is initiated by a client and related content is written to the server. In this system, the written content has nothing to do with the business. All the written content is abstracted as a technical layer for processing.

2. function prototype

Public byte [] writedata (string schemaname, byte [] content, string password)

2. Parameters

Schemaname

Similar to reading functions.

Content

The content to be written is generated on the client. First, an XML file is generated, which corresponds to schemaname. After the XML file is generated, operations such as compression and encryption are performed on the client, generate a binary byte array and upload it to the server.

Password

Similar to reading functions.

2. Return Value

Similar to the reading function, if a byte array is returned, the client first needs to extract and decrypt it before using it. Although a small amount of content is compressed after being returned, it is larger, but for a unified management method, still working in this way.

ØData Transmission

Data is transmitted in two directions, that is, some are written to EBS from a third-party system, and some are read from EBS and returned to a third-party system.

For one-way read (EBS-> third-party), there is no risk of data consistency. You can directly return the data. You can control the data security and effectiveness by adding and configuring the schema.

However, for another aspect of transmission (third-party-> EBS), there is a sensitive issue, because the EBS data structure is very complex, it is difficult to fully grasp its structure, therefore, to transfer data in this direction, we must grasp the principle that the data can only be written to the EBS interface table and cannot be directly written to the production table. This part will be described in more detail in the schema section.

In the next installment, we will introduce the system security in detail.

Iv. Security System

In the previous chapter, we also mentioned data security and some strategies. Here we will detail secure data transmission.

ØSSLSystem

This is a network-layer solution. The specific solution is to configure the corresponding SSL certificate on IIS to implement an SSL site. The security certificate adopts Verisign and can be purchased from a Chinese agent.

The SSL method increases the security of the system, but it also has a slight impact on the performance, but it will not become the performance bottleneck of the system.

In addition, you also need to verify whether all third-party vendors support this SSL method when writing programs. Therefore, this system is available as an optional component and can be enabled at any time without affecting the overall architecture.

ØCompression and Encryption

If SSL is not used for data communication between the client and the server, the information on the Internet can be intercepted and cracked. To solve this problem, data must be pre-processed before transmission.

Compression is a required option. The standard ZIP compression algorithm is used to compress and decrypt the client. The client determines which tool is used and does not provide special processing functions.

For encryption algorithms, you can use standard encryption algorithms, simple encryption algorithms defined by yourself, or encryption algorithms that are not considered for the time being. compression is used only for processing. encryption algorithms are not considered for the time being.

ØPassword string (identifier)

The system assigns a unique identifier to each third-party vendor (system). To enhance the strength of the identifier, a 32-byte password string is used, which has no meaning, as a unique identifier only, increasing the length reduces the risk of theft.

For distribution of password strings, you only need to handle them manually without considering program implementation. You can send them via email.

To verify the password string, both the server side and the client side need to store the password string for verification. The server here refers to the WebService server, not the EBS server, because it is not convenient to add too many customized content to the EBS.

On the server side, you can directly use XML files or flat files to store password strings. This can be decided upon implementation. In the file, you only need to simply store the following information:

2. password string

The character string used for communication. It is 32 bytes long and can be manually generated and generated without any rules. It can be correctly delivered to the relevant third-party vendor.

2. vendor name

This identifier is not used in the system.

2. Effective start date

This password string is considered legal only after the date is exceeded. This field cannot be blank and special cases can be handled by a very small date.

2. Valid end date

The password string is considered valid only when it is earlier than this date. This field cannot be blank and can be regarded as indefinite by a large date. The above two dates can be adjusted at any time, to change the password availability.

2. creation date

The date on which this record is added.

2. creator (string description)

Who added this record.

2. last modification date

2. Last Modifier

When IIS is started on the server, add special processing to the instance_startup function to read all the password strings and put them into the global variable (only one field of the password string is read, otherwise, check whether the input password string parameter is valid in the getdata/writedata function of WebService, if it is illegal, an error such as "invalid use" is returned directly.

The verification function is as follows:

Private bool validpassword (string password)

After the client receives an email from the headquarters about the password, all operations must carry the password. If the password is incorrect, it may cause a series of errors, and the third party must be sure of the password.

Password Change:

Change the valid end date of the original password on the server and record the change;

Add a new record and confirm that the end date is valid;

Finally, the new password is sent to a third-party vendor.

ØDatabase Table ACL

In principle, the client reads and writes data according to the agreed rules. to prevent malicious reads and writes, the client sets the ACL here to control which tables can be read and written, and the ACL file is a standard XML file, it includes the following three attributes:

2. Table name (in upper case)

2. readable (bool type)

2. Is it writable (bool type)

Similarly, when the system is started, the information will be read into the memory for backup.

ØPrivate Information

In the same interface table, operations may be performed by multiple vendors at the same time. In this case, to ensure that operations between different vendors do not affect each other, you need to find a suitable field in the corresponding interface table, to store the manufacturer's password string.

In the subsequent sections, we will describe the schema, which is the basic unit of data communication.

V. XML Schema

To achieve more universal interaction, schema is the most important part.

The schema here is a standard template XSD document that complies with all standard specifications.

For more information about XML schema, see the official website.

Schema is used to read and write data. schema is used to map the original table.

Both the WebService server and the client have a schema list that stores all schemas on the server. However, on the client, only the components related to your own business are stored, all schemas are not stored.

ØData Reading

The schema file is used to describe the data, but has no dependency with the database itself. You need to obtain an SQL statement based on the schema to retrieve data from the database. To convert schema and SQL statements easily and quickly, you can write another special file with the same file name and schema extension. select indicates an SQL statement for selecting data. This file only exists on the server, and the client does not know the existence of this file. In the instance_startup function, all the related SQL statements are read into the memory at one time to facilitate later use. Of course, if there is any change to this file, IIS must be restarted.

For the where condition, you can use it as a string directly after the SQL statement to obtain a real SQL statement. SQL does not have the parameter concept. The spliced SQL statement can be directly used in the database, to ensure SQL availability, the client must follow certain rules when writing the where condition, including the matching relationship such as and/or and the use of parentheses/single quotes.

There are two solutions to generate standard XML:

If Oracle10g supports xml SQL, XML files that comply with the XSD standard can be generated directly;

If not, only one dataset can be returned. Then, manually generate an XML file based on the schema format.

After the XML file is generated, the compression toolkit is called to compress it, generate a binary array, and return it directly.

If an error occurs during use, a query error is returned.Code, You can return the relevant error code.

Before reading the table, you need to determine whether the table is readable in the ACL list (if not, skip this step because the SQL statement cannot be changed by the client ).

ØData Writing

The data writing function contains a byte array, which is first extracted and decrypted to generate an XML file. This file works with the schema and is read into the system as a standard dataset, in this case, you can use the existing technology to directly write the content to the database. before writing the content, you must go to the ACL to check whether the table can be written.

6. EBSRelated Operations

All write operations are written to the interface table of EBS and will not be directly written to the formal table. Therefore, after writing to the interface table, you need to call the standard request of EBs to write the interface table to the formal table.

For interface tables, different modules have different interface tables with different operation methods and different requests for implementation. Therefore, based on the actual interface situation, consider the EBS interface table and standard request, and study the error information and meaning returned by the standard request. There is also the storage location returned by the error, and some are directly written back to the interface table, some will be written to the standard error log table, which will be determined during the operation.

VII,Summary

The above methods have been applied in our company and have been used in multiple business systems. They have good use results. I hope you can help me with your reference.