Oracle and PHP Instance development Myers Order tracking System

Case studies on how the Php/oracle development model shortens the application lifecycle on the Myers Internet.

For companies that are primarily driven by the receivables business model, one of their core business functions is to enter, track, and record orders. Better companies in this area can scale their institutions and increase their profits without encountering infrastructure constraints. When order Processing is cumbersome, error-prone, or inconsistent, the company will suffer economic losses due to direct costs and reduced productivity.

With my company Myers the Internet, the core business revolves around building the customer base, providing continuous service to Myers, and helping it solve problems when customer problems arise. Companies are using many different systems to handle various aspects of the order entry and implementation cycle. These systems are not integrated with each other and do not have the mechanism to ensure that each order is properly accounted for.

Myers Order Tracking System (MOTS)

Like many other institutions, Myers has grown from a small company to a midsize company, while maintaining the same processes and systems throughout its growth. When most of these processes are established, all transactions are done manually by e-mail, paper-based records, and field visits. 5 or 6 years ago, a Myers engineer used Allaire's Cold Fusion and a Microsoft SQL Server database to assemble a system to track order implementation, a system called MOTS (Myers Order tracking system) that allows sales and The account management Department enters the order and then implements the orders by the support, engineering, design, information systems and accounting departments. Although this system is an important step forward, it still has many manual steps and is not integrated with any other business systems.

At about the same time, a system was created in which customers and sales reps could order the products of the Myers website online. This system creates a new Web site and calculates the sum of the installation and recurring costs of the provided Web site package. It then sends an e-mail message to various departments, which can enter the order into the Mots and create accounting information in the account management system.

Architecture Barriers

This type of architecture suffers from several system problems. In Myers, one of the more obvious issues is the manual data input required to initiate order tracking, as well as the errors that occur as a result of this manual process. Another problem is the disconnect between order entry, order tracking, and billing systems in the company, lost orders, missing information, and errors caused by it.

Another problem that only occasionally arises is that the MOTS system itself has inherent flaws. Because of the way you write Mots, you can enter orders that do not have departmental distribution information or that have lost departmental distribution information. When this happens, the order will eventually be lost in the system. When the order is lost, accurate and timely accounting is more difficult to achieve.

As the business grows, the flaws in the architecture become more and more apparent, and as customers and orders increase, the number of lost and wrongly entered orders becomes more frequent, resulting in an immeasurable impact on the company's revenue. In addition, the amount of data that has been manually entered causes delays and inefficient processing.

Because of the increased and inefficient impact on revenue in implementing agencies, it is clear that a replacement system is needed to link everything up and improve efficiency and reduce error rates. The old system is illustrated below.

　

Figure 1: The old system architecture

The figure shows all the areas that require manual data entry. Since none of these systems are integrated, the likelihood of data loss or distortion is very high. Global demand immediately became apparent.

The order system needs to be linked directly to the implementation tracking system. The system requires security to prevent orders from leaving the system before it is processed. Need to maintain accuracy to ensure accurate accounting and correct order implementation. The system needs to minimize internal costs. So, to do that, you need to create the system quickly, but the system must have complete functionality.

While a good order entry and tracking system can help reduce costs, it does not generate revenue in itself.

Deep structure

Before you start the pattern design, you need to address some of the basic architectural issues. The first underlying technical requirement is that the system must be configurable and require no additional coding. In essence, this means that workflows need to be embedded in the database rather than interpreted/processed code for hard coding. Second, the database needs to contain enough information to be able to represent the main (and changing) aspects of the order entry interface as well as the implementation process.

In the process of working out the above problems, the system is becoming more and more suitable for two parts-order entry and order tracking, and provides a clear definition of the relationship between the two. The order entry system needs to know how to represent orders with accurate product codes, discounts, and pricing terms. The order implementation system needs to know how to track various types of tasks, related jobs, and departments to process and record each order. Finally, the order needs to be translated into implementation operations on a regular and predictable basis. The following figure shows the structure of the new system currently in existence.

　

Figure 2: The new system architecture

The figure shows all the information paths to the new Order system, and the New Order system is located on the back-end portal management site. All initial data entries are completed only once, and each team is required to validate the data at each stage of processing. By introducing automatic data transfer from the order system to the account management system, another major area of vital data transfer becomes automated.

Rely on PHP

At a purely technical level, early decision to use PHP as the primary development language and Oracle as the database for the system has several main reasons. First, the Myers existing back-end portals are almost entirely written with PHP based on an existing Oracle database, eliminating a potential source of incompatibility. This also means that to create this new system, Myers can leverage its capabilities to create an existing back-end portal.

Second, experimental tests show that PHP provides a high level of performance compared to other development languages. Because PHP resides within the Apache server as a dynamically loaded repository, no additional startup time is required for each connection to the system. In addition, improvements to PHP optimizations (through the Zend project) mean that normal operations performed internally within the code are not noticeably slower. Finally, the OCI interface module written for PHP is compiled and optimized with C code, which makes access to the Oracle database very efficient.

Third, we understand that because the PHP code embeds itself into the HTML environment, it becomes more natural for designers and programmers to create collaborative user interface functionality code. While this last feature is available in other server-side scripting languages, Myers found that PHP is less likely to lead to conflicts between developers and designers. In addition, the syntax of PHP and the provided code base mean that it can do all the things it needs to do.

Finally, another benefit of embedding all of your code in your HTML code is that you can control the source code simply by modifying the standard text file. We use CVS as its standard to modify the control system. Because the PHP code does not have to be compiled in a certain way, one "compile" of the system involves retrieving the text source code files from the repository and then putting them on the Web server. This means that we can use the control mechanism in CVS to release an incremental bug patch for its test and production environments without creating a complex compilation system.

Design pattern to support reconfiguration

The following basic pattern diagram shows how the order system is built. Both of the main patterns are divided into prototype tables and transaction tables. Whenever the business situation changes, the prototype table allows the system to be reconfigured without recoding. The transaction table contains order details and job details for the actual customer order.

　

Figure 3: Schematic diagram of the basic pattern

Figure 4: Schematic diagram of the basic pattern

These pattern diagrams look very complicated, of course, they are really complicated. However, if you separate them so that only the prototype table (the table ended in _def) is present, the infrastructure of the architecture becomes clear. Orders are made up of row groups, which include details, order lines, or both. An order line can create a job randomly, a job consisting of a sequence of tasks, and contains several details. You must enter these details for various tasks. Tasks appear in different queues, which can be accessed by specific users in different departments.

In order to test the system, the strategy is to prototype the order system in a phased format. The first part of the system to test is its ability to create a clear order from the Order prototype table alone. Once the original schema definition is complete, the Order Builder is the first visible part of the prototype system.

The team consisting of building and configuring this system includes three developers, in addition to the managers of the departments that are most affected by the system. The developer's Division of labor is: Build configuration function, display function and transaction processing function. Throughout the initial build cycle, department managers provided valuable feedback on the types of interfaces that enable users to enter and process data.

Draw user interface with PHP

The initial order to be prototyped is the basic WEB site order, provided on the webwiz.myersinternet.com/. The resulting order was created by a developer in PHP within three days of the time. If the order prototype definition-relies on only one layer of PHP code between the database and the browser-to fully define the appearance and behavior of the order entry, a degree of compromise is required in the database design. To do this, a structure such as an order line group must support two uses: (1) provide a visual distinction on the input form so that similar product groups can be drawn Together (2) from functional to a similar group of goods, such as a certain discount of goods, or a list of options, from which you can make the only choice.

Because PHP is the language of development, the prototype is built fairly quickly so that the required modifications to the pattern can be completed quickly and the form generator is encoded (one after the other). In addition, because patterns are designed to take into account the user interface of the drawing, it is easy to modify and adapt the schema when new visual requirements are presented in the prototype build process. The resulting form looks similar to the following illustration:

　

Figure 5: Order generation

To create a fully functional system

After you provide the order, you need to make it fully functional. First, the system needs to save the order data that is entered in the order for transactional processing. Second, the person filling out the order needs to be able to fill in according to the order data in progress.