マイヤーズ注文追跡システムを開発するための Oracle と PHP の例

Myers Internet で PHP/Oracle 開発モデルがどのようにアプリケーションのライフサイクルを短縮したかに関するケーススタディ。

主に売掛金ビジネス モデルによって推進されている企業にとって、中核的なビジネス機能の 1 つは注文の入力、追跡、記録です。これに優れた企業は、インフラストラクチャの制約に遭遇することなく組織を拡大し、利益を増やすことができます。注文処理が煩雑で、エラーが発生しやすく、または一貫性がない場合、企業は直接コストと生産性の低下によって財務的に苦しみます。

私の会社、マイヤーズ インターネットでは、顧客ベースの構築、マイヤーズへの継続的なサービスの提供、顧客の問題が発生した際の解決の支援を中心にビジネスの優先事項を展開しています。企業は、注文入力と履行サイクルのさまざまな側面を処理するために、さまざまなシステムを使用しています。これらのシステムは相互に統合されておらず、すべての注文が正しく処理されていることを保証するメカニズムもありません。

マイヤーズ注文追跡システム (MOTS)

他の多くの組織と同様に、マイヤーズも同じプロセスとシステムを維持しながら中小企業から中規模の企業に成長しました。これらのプロセスのほとんどが確立されていたとき、すべての取引は電子メール、紙の記録、サイト訪問を通じて手動で行われていました。 5、6 年前、Myers のエンジニアは、Allaire の Cold Fusion と Microsoft SQL Server データベースを使用して、MOTS (Myers Order Tracking System) と呼ばれる注文処理を追跡するシステムを構築し、販売部門とアカウント管理部門が注文を管理できるようにしました。サポート、エンジニアリング、設計、情報システム、および会計部門によって入力され、実装されます。このシステムは重要な前進ですが、依然として多くの手動ステップが残されており、他のビジネス システムと統合されていません。

同時期に、顧客や営業担当者がマイヤーズのウェブサイトからオンラインで商品を注文できるシステムも構築されました。このシステムは、新しい Web サイトを作成し、提供された Web サイト パッケージの合計インストール費用と経常費用を計算できます。その後、さまざまな部門に電子メールが送信され、部門は MOTS に注文を入力し、アカウント管理システムで請求情報を作成できます。

アーキテクチャの障壁

このタイプのアーキテクチャには、いくつかのシステム問題があります。マイヤーズ社では、より顕著な問題の 1 つに、注文追跡を開始するために必要な手動データ入力と、この手動プロセスの結果として発生するエラーが含まれていました。もう 1 つの問題は、社内の注文入力、注文追跡、請求システムの間の切断、注文の紛失、情報の欠落、およびそれらによって引き起こされるエラーです。

時折しか発生しないもう 1 つの問題は、MOTS システム自体に本質的に欠陥があることです。 MOTS の記述方法により、部門割り当て情報がまったくない、または欠落している注文を入力する可能性があります。これが起こると、最終的にはシステム内で順序が失われます。注文が失われると、正確かつタイムリーな会計を達成することが難しくなります。

ビジネスが成長するにつれて、アーキテクチャの欠陥がますます明らかになり、顧客と注文の数が増加するにつれて、注文の紛失や誤入力がより頻繁に発生し、会社の収益への影響が大きくなります。測定。さらに、手動で入力されたデータの量により、遅延や処理の非効率が生じていました。

収益への影響が増大し、実施機関内の効率が低下したため、すべてを結び付けて効率を高め、エラー率を下げるには代替システムが必要であることが明らかになりました。旧システムを以下に示します。

図 1: 古いシステム アーキテクチャ

この図は、手動データ入力の必要性を示しています すべての領域。これらのシステムはどれも統合されていないため、データの損失や歪みが発生する可能性が非常に高くなります。大局的なニーズがすぐに明らかになりました。

注文システムは実装追跡システムに直接リンクする必要があります。このシステムには、注文が処理されずにシステムから流出することを防ぐためのセキュリティが必要です。正確な請求と正しい注文履行を保証するには、正確性が必要です。システムは内部コストを最小限に抑える必要があります。したがって、それを実現するには、システムを迅速に作成する必要がありますが、そのシステムが完全に機能する必要があります。

優れた注文入力および追跡システムはコストの削減に役立ちますが、それ自体で収益を生み出すわけではありません。

構造の詳細

パターン設計を開始する前に、対処する必要がある基本的なアーキテクチャ上の問題がいくつかあります。最初の基本的な技術要件は、追加のコーディングなしでシステムを構成できる必要があることです。これは基本的に、ワークフローを解釈/処理コードでハードコーディングするのではなく、データベースに埋め込む必要があることを意味します。次に、データベースには、注文入力インターフェイスの主要な (そして変更可能な) 側面を表現し、処理を実装できる十分な情報が含まれている必要があります。

上記の問題を解決しようとする過程で、システムは注文入力と注文追跡の 2 つの部分に徐々に適応し、この 2 つの間に明確に定義されたリンクを提供しました。注文入力システムは、正確な製品コード、割引、価格条件で注文を表現する方法を知っている必要があります。注文処理システムでは、各注文を処理して記録するために、さまざまな種類のタスク、関連ジョブ、およびさまざまな部門を追跡する方法を知る必要があります。最後に、注文は定期的かつ予測可能なベースで実装ジョブに変換される必要があります。現在の新システムの構成を次の図に示します。

図 2: 新しいシステム アーキテクチャ

この図は、新しい注文へのパスを示しています すべての情報パス新しい注文システムは、バックエンドのポータル管理サイトにあります。すべての初期データ入力は 1 回だけ行われ、各グループは処理のさまざまな段階でデータを検証するだけで済みます。重要なデータ転送のもう 1 つの主要領域も、注文システムから会計システムへの自動データ転送を導入することによって自動化されます。

PHP への依存

純粋に技術的なレベルで言えば、主な開発言語として PHP を使用し、システムのデータ リポジトリとして Oracle を使用するという初期の決定には、いくつかの主な理由がありました。まず、Myers の既存のバックエンド ポータルは、既存の Oracle データベースに対してほぼ完全に PHP で記述されており、非互換性の潜在的な原因が排除されました。また、この新しいシステムを作成するために、マイヤーズは既存のバックエンド ポータルを作成した独自の機能を活用できることも意味しました。

2 番目の実験テストでは、他の開発言語と比較して、PHP が比較的高いパフォーマンス レベルを提供することが示されています。 PHP は動的にロードされるデータベースとして Apache サーバー内に存在するため、システムへの接続ごとに追加の起動時間は必要ありません。さらに、(Zend プロジェクトによる) PHP 最適化の改善により、コード内で実行される一般的な操作が著しく遅くなることはありません。最後に、PHP 用に作成された OCI インターフェイス モジュールは C コードでコンパイルおよび最適化されているため、Oracle データベースへのアクセスが非常に効率的になります。

3 番目に、PHP コードは HTML 環境に埋め込まれるため、デザイナーとプログラマーが共同でユーザー インターフェイスの機能コードを作成することがより自然になることがわかりました。この最後の機能は他のサーバーサイド スクリプト言語でも利用できますが、マイヤーズ氏は、PHP は開発者と設計者の間で衝突を引き起こす可能性が低いことを発見しました。さらに、PHP の構文と提供されるコード ベースは、必要なすべてのことを実行できることを意味します。

最後に、すべてのコードを HTML コードに埋め込むことのもう 1 つの利点は、標準のテキスト ファイルを変更するだけでソース コードを制御できることです。標準改造管理システムとしてCVSを採用しております。 PHP コードは特定の方法でコンパイルする必要がないため、システムを作成するための「コンパイル」には、単にリポジトリからテキスト ソース コード ファイルを取得して Web サーバーに配置することが含まれます。これは、複雑なビルド システムを作成することなく、CVS の制御メカニズムを使用して、テスト環境と運用環境に増分バグ パッチをリリースできることを意味します。

再構成可能性をサポートする設計パターン

以下の基本パターン図は、注文システムがどのように構築されるかを示しています。 2 つの主要なスキーマは、プロトタイプ テーブルとトランザクション テーブルに分かれています。ビジネス状況が変化するたびに、プロトタイプ テーブルを使用すると、再コーディングせずにシステムを再構成できます。トランザクション テーブルには、実際の顧客注文の注文詳細とジョブ詳細が含まれます。

図 3: 基本モード図

図 4 : 基本的なパターン図

これらのパターン図は複雑に見えますが、もちろん実際は複雑です。ただし、プロトタイプ テーブル (_def で終わるテーブル) のみが表示されるようにこれらを分割すると、アーキテクチャの基本構造が明確になります。注文は、詳細、注文明細、またはその両方を含む明細グループで構成されます。注文明細では、オプションで、一連のタスクで構成され、いくつかの詳細を含むジョブを作成できます。これらの詳細は、さまざまなタスクで入力する必要があります。タスクはさまざまなキューに表示され、さまざまな部門の特定のユーザーがアクセスできます。

システムをテストするための戦略は、段階的に注文システムのプロトタイプを作成することです。システムの最初に検証する部分は、注文プロトタイプ テーブルのみから明確な注文を作成する機能です。初期スキーマ定義が完了すると、オーダー ジェネレーターはプロトタイプ化されたシステムの最初に表示される部分になります。

システムの構築と構成のために結成されたチームには、システムの影響を最も受けた部門のマネージャーに加えて、3 人の開発者が含まれていました。開発者の役割分担は、構成機能、表示機能、およびトランザクション処理機能の構築です。初期の構築サイクルを通じて、部門マネージャーは、ユーザーがデータを入力して処理できるようにするインターフェイスの種類について貴重なフィードバックを提供してくれました。

PHP を使用してユーザー インターフェイスを描画する

プロトタイプへの最初の順序は、基本的な Web サイトの順序であり、webwiz.myersinternet.com/ で入手できます。結果として得られた注文は、PHP を使用して 1 人の開発者によって 3 日で作成されました。注文プロトタイプの定義 (注文入力の外観と動作を完全に定義できる) が、データベースとブラウザーの間の PHP コードの 1 層のみに依存している場合、データベース設計にはある程度の妥協が必要です。これを行うには、注文明細グループなどの構造が 2 つの目的をサポートする必要があります。(1) 類似した製品グループをまとめて描画できるように、入力フォーム上で視覚的に区別できるようにする。 (2) 機能的に類似したアイテムをグループ化する。特定の割引、または独自の選択ができるオプションのリスト。

PHP は開発言語であるため、プロトタイピングは非常に高速であり、スキーマに対する必要な変更を迅速に行い、フォーム ビルダー用に再コード化することができます (1 つずつ)。さらに、パターンは描画されたユーザー インターフェイスを念頭に置いて設計されているため、プロトタイピング プロセス中に新しい視覚化のニーズが発生した場合でも、パターンの変更や適応を簡単に行うことができます。生成されたフォームは次の図のようになります。

図 5: 注文の生成

完全に機能するフォームの作成システム

注文を提供した後、完全に機能するようにする必要があります。まず、システムはトランザクション処理のために注文に入力された注文データを保存する必要があります。次に、注文を記入する人は、進行中の注文データに基づいて注文を記入できる必要があります。