Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
System Design Alternatives
Let's start looking into the issues and challenges. Figure 1 is a high-level view of the system context diagram for the order tracking system and Figure 2 depicts the detailed analysis of the requirements for this integration project. Figure 2 shows that the data is represented as a file, hence a passive data source.
)
Figure 1 High-level View of the System Context Diagram.
)
Figure 2 Logical Design of the System.
Based on the detailed analysis, we can break the integration project into the following four small projects:
Implementation of order-tracking data and order-entry processing
Consolidation of product data
Consolidation of customer data
Creation of a web interface
From a project-management perspective, it is obvious that the first priority is the creation of a web interface because as soon as the other projects are available, they can be bound together with the web interface. However, it would be even better to further divide the first three projects into small deliverables instead of doing the whole deliverable as one large project. First, it benefits the organization to quickly realize the benefit of part of the functionality; second, if we design the whole project as one big project, we may end up making some mistakes—either in design or in managing the complex project as a whole. Whatever way you look at it, you still have to do a lot of work, but it reduces the complexity of the design and management of the project.
Let's discuss how we can make the new interface flexible enough from the existing application. There are number of conventional methods used to integrate the new interface with the existing system, but there are several issues to deal with—discussed in the following sections below. Figure 3 shows some of the techniques that can be used in the project.
)
Figure 3 Alternate Solutions.
Screen-Scrapping
If the front-end web server is calling an existing application by screen scrapping and sending and receiving the data for inquiries and transactions as a result, it must perform the following tasks:
Log on to the back-end system.
Perform any menu traversal if required.
Reformat the data from the existing to new format strings and from new to existing format strings.
Keep track of the dialog between the new interface and the existing interface.
During the error-handling situation in the existing application presentation layer, it is difficult for the new interface to know the type of errors and ways to recover them, especially if a network error occurs.
Any changes in the existing interface have ramifications for the front-end interface. Changing onscreen and fixing the problem does not impact as much as when several screens are changed in the existing applications. On the contrary, it has a severe impact on the new interface.
Large Message
Some large message situations are difficult to implement, especially if it is coming out of the new web interface and corresponding to five different messages of the back-end system. Let's assume that while processing the third message at the back-end system, the transaction aborts. Now, the programs must undo all the work that first two transactions have completed. The best solution is to process the large message as a whole two-phase commit transaction, but if you are emulating a terminal, you do not have the capability for a two-phase commit. Instead, you have to perform a manual type of process to recover the first two transactions. The human intervention process can make some judgments and recover the data. The human operator makes a valued judgment that some of the updates are okay and some aren't. They even resubmit the input, just leaving out the single field that caused the error. In the worst case, during this automated process of recovering the data through the existing interface, the error that occurred on the network would make this process even more difficult.