1. 序文: プロジェクトの背景
プロジェクトの状況:ある企業は、電子商取引プラットフォームを通じて日用清掃製品を主に販売しており、タオバオは垂直カテゴリーで第 1 位にランクされています。また、クライアント企業には運用保守やプロジェクト環境の準備を自社で行える小規模な開発チームがあり、要件は主にクライアントの開発と確認します。
プロジェクト要件:チャネルによって作成された注文を王迪通 ERP に同期するには、元の王迪通 ERP システムに接続できる拡張システム (つまり、サプライ チェーン管理プラットフォーム) が必要です。ERP で同期されます。
プロジェクト期間： 14営業日（2週間半）
参加人数： 2名（プロダクトマネージャー1名、フルスタック1名）。
プロジェクトが開始されました....1 2 3 行き
2. 1-2 日目: 需要調査
プロジェクト契約締結後は、できるだけ早く需要調査の日時、場所、計画などについてお客様と交渉させていただきます。その後、研究活動の手配をします。
今回のプロジェクト（サプライチェーンマネジメントプラットフォーム）は、プロジェクト要件がそれほど複雑ではないため、2日間の調査サイクルを組んで顧客先へ赴き、対面で確認を行いました。
研究結果: Zhixin のローコードで構築する必要があるシステムは、チャネル エンドとオペレーション エンドの 2 つの操作ポートに分かれており、Wangdiantong ERP に接続する必要があります。
運用面：社内担当者がチャネルや注文情報の管理に参加。
チャネル側:チャネル加盟店のログインをサポートし、Wangdiantong ERP の注文操作動作とのリアルタイムのデータ同期を実行します。
基本的な注文動作に加えて、チャネルウォレット機能も必要で、チャネルから開始された返品はチャネルウォレットの形で返され、ウォレット内の金額は次回以降の支払いで差し引かれます。(これは現地調査で見つかった追加の拡張要件ですが、ローコード実装で作業負荷がそれほど増加しないと推定されるため、追加します)
関係事業者へのヒアリングをもとに整理した業務フロー図は以下の通りです。従来の開発と同様に、このステップを保存することはできませんが、完全なロジックと詳細なステップを含むフローチャートにより、将来的には開発時間を大幅に節約できます。
3. 3 ～ 4 日目: モデルのコーミング
サプライチェーンマネジメントプラットフォームの需要調査が完了し、詳細な業務プロセスロジックをお客様と確認した後、需要の仕分け作業を開始します。
いわゆるナイフを研ぐことは、間違って薪を切ることはありません。
要件を整理および分析し、対応する技術的解決策を決定することは、システム開発において非常に重要なステップであり、ローコード開発モデルも例外ではありません。
1. ローコード モデルの結合:
ローコード開発のプリモデル結合は主に「機能モジュール - テーブルモデル - フィールド設計」に分かれています。
これはローコードの「アプリケーション-モジュール（データテーブル）-フィールド構造」にも相当します。
まずモジュールのリストを整理します。
次に、モデル モジュールをモジュールごとに並べ替えます。
2. 試作・機能設計段階
モデルとインターフェースを整理したら、プロトタイプと機能設計の段階に入ります。
ローコードの開発と構成が急速に進んでいるにもかかわらず、プロトタイピングには従来のプロトタイピング ツールを使用しており、その主な目的は、お客様のニーズにできる限り一致することです。ローコード プラットフォームに束縛されることはありません (もちろん、これをサポートするローコード プラットフォームの強力なカスタマイズ機能にも基づいています)。
ここでは、プロダクト マネージャーに、インタラクションの速度を向上させ、可能な限りローコード インタラクションに適合できる、文字を編むためのコンポーネント ライブラリを作成するよう依頼します。
特別なニーズがある一部のページについては、プラットフォームのカスタム ページを通じて実現できるカスタマイズされたデザインも完全にサポートできます。
最後に、すべてのモデルとプロトタイプをユーザーに確認するという非常に重要なステップです。確認が完了したら、ローコード テクノロジのレビュー フェーズを開始して、この開発のテクノロジ導入計画を決定します。
4. 5日目: 技術レビュー
難易度 1: 王迪通 ERP データ ドッキング ソリューション
ERP の注文と注文の 2 つのモジュールがローコード プラットフォームに確立されています。その中で、ERP注文は王迪通ERPのクエリ注文インターフェイスを呼び出し、定期的に王迪通ERPの注文情報を取得し、そのテーブル構造はクエリ注文インターフェイスの戻りパラメータと一致します。
注文テーブルには、ローコード プラットフォームで作成された注文情報が保存されます。作成が完了すると、王迪通 ERP の注文作成インターフェイスが呼び出され、注文情報が王迪通 ERP に転送されます。注文テーブルでは、テーブルを定義できます。顧客構造のニーズに応じて、注文を作成するためのインターフェイスの受信パラメータの必須フィールドが正しく渡されることを確認するだけで済みます。注文と ERP 注文の両方に元の注文番号があるため、このフィールドを一意の識別子として使用して、注文ステータス、物流注文番号などの ERP 注文の情報を注文に同期させることができます。データ同期の要件。
実際の使用においては、ユーザーは注文テーブルを操作するだけで、注文の発注と注文状況の同期が完了します。
難易度 2: 各モジュールのデータ分離スキーム
チャネルプロバイダー管理システムは、チャネル側と運用側の2つの操作ポートに分かれており、運用側では管理しているチャネルの全情報を閲覧でき、チャネル側では全情報の閲覧のみが可能です。自分のチャンネルの。
上記の要件に基づいて、最初に view メソッドを使用してチャネルの操作モジュールを確立します。また、ユーザーの拡張パラメータを自動的に設定することで、チャネル ユーザーのチャネル ID がユーザー情報にバインドされ、統合データ フィルタリングをチャネル操作モジュールに追加するだけで、チャネル端でのデータ分離を実現できます。
操作側においても、操作で閲覧できるチャンネル情報をユーザー拡張情報に自動設定し、操作可能な各モジュールにデータフィルタリングを追加することで、操作側でのデータ分離を実現します。
難易度3：チャンネル情報の作成・変更検討
顧客が変更を希望する場合、基本情報、組み合わせパッケージ、契約書を一括して編集および報告することができ、変更開始後、財務部門によるレビューが行われ、レビューが通過した後、変更内容を報告することができます。チャンネル情報と同期します。
この要件を踏まえ、変更内容を格納するチャンネル情報テーブル一式を再作成し、ワークフローによる承認機能を実装し、承認後にチャンネル情報に変更データをコピーしました。
難易度4：注文ページの特殊インタラクションの調整
顧客は注文時の商品選択時に商品の内容をカード形式で表示したいと考えており、注文プロセス全体は、最初に商品を選択し、次に配送先住所を入力する2つのステップに分かれています。
商品をカード形式で表示：独自の検索リストをフォーム形式で表示すると同時に、顧客がデフォルトで注文できる商品、および注文が必要な商品を読み込みます。お客様が数量を記入します。
ステップバイステップ注文: 注文の動作はデータを作成することなので、商品をグループ化し、配送先を選択し、作成時にステップバイステップ表示を有効にします。
これまでのところ、顧客のサプライチェーン管理ビジネスに基づいた需要の仕分けが完了し、次の段階は正式にローコード開発リンクに入ります。
紙面の都合上、ご注目くださいませ 次回は引き続き、プロジェクト実戦第二段階「ローコード関数開発」をお伝えします。