Bitrix24-CRM以上ですか？

多くの場合、最良の決定は、まったく予想されていない場所から行われます。 「思考ランプ」が頭の上で点灯したらすぐに、普通の物をわずかに異なる角度から見るだけです。

私たちのチームでも、クラスのスケジュールを管理し、大学生の会計を管理するシステムを開発するタスクを受け取ったときに、まったく同じ話が起こりました。

結果として、クラウドCRM Bitrix 24用のアプリケーションを開発することで問題を解決することができました。

このケースの例では、このcrmがどのように使用されるかを一見しただけで示しますが、標準的な目的ではありません。 私たちの経験が、bitrix24のカスタム統合のタスクに直面し、少なくともそのようなソリューションに刺激を与えることに役立つことを願っています。

挑戦する

このプロジェクトは、以前にクライアントのために立ち上げたサイトの論理的な継続となりました。

このサイトにはすでにスケジュールがありましたが、便利な管理と、学習プロセスの参加者（教師と生徒）のための内部のパーソナライズされたスペースがありませんでした。

基本的な要件を収集した後、およそ次のリストを取得しました。

• スケジュール管理システム
  
• 送信スケジュール変更SMS
  
• 勤怠会計、パフォーマンスジャーナル
  
• 文書の交換を含む、生徒と教師間のコミュニケーション
  

率直に言って、Bitrix24は作業環境です。 私たちはユーザーの観点からそれをよく知っています。 ここでは、プロジェクトの実施、ドキュメントの交換、顧客とのコミュニケーション、トラッカーでのタスクの実施を行っています。

また、タスクが到着するまでに、b24のアプリケーションの開発でいくつかの経験がありました。

• テクニカルサポートの負荷を監視するタスクを解決するアプリケーションを作成しました
  
• b24向けの最初の商用チャットボットをリリース
  
• Googleアナリティクスとコールトラッカーを使用して、エンドツーエンドの分析ソリューションをまとめる
  

しかし、Sibiriks社のかんばんボードを除いて、多かれ少なかれ深刻な統合は、その時点ではわかりませんでした。

bitrix24のアプリケーションはあなたの開発であり、サイトでホストおよび実行できますが、iframeを介してbitrix24ポータルに組み込まれます。 この統合により、Oauth 2.0承認の使用が可能になり、APIを介してポータルデータの処理が提供されます。

この場合、 Bitrix24は「ブラックボックス」になり、必要に応じてソリューションを実装できます。 たとえば、記事の終わり近くで、React + Laravelをスタックに追加しました。

bitrix24のアプリケーションは 、サービスに存在する機能では解決できない問題の解決策です。

つまり、たとえば、タスクまたは他のエンティティのリストの「基本」表示に満足できない場合、必要に応じてタスクのリストを表示できる独自のアプリケーションを実装できます。 Bitrixエンティティのデータまたはその特性を使用して操作を自動的に実行する必要がある場合は、カスタムソリューションを使用して解決することもできます。

しかし、bitrix24はまずCRMシステムであり、教育プロセスを自動化するためのポータルはどこから来たのでしょうか？

実際、bitrix24をタスクのプラットフォームとして使用することは魅力的に見えました。

ほぼ「箱から出してすぐ」に、機能的なワーキンググループを使用することで、生徒と教師の間のコミュニケーションの問題を解決しました。 ワーキンググループを正しい角度から見る必要がありました。

グループは教育的であることができます-学芸員と教師と学生を結びつけて、グループのために地元の情報の交換を可能にします。

物理、化学などのグループを主題にすることができます。b24の機能のおかげで、そのようなグループでは、主題に関する情報の「知識領域」を簡単に整理できます。 これには、必要なすべての機能があります。

• ファイルストレージ
  
• ニュースフィード
  
• ウィキ
  
• チャット
  

モバイルバージョンのポータルで自動的に利用できるチャットボットを開発するためのプラットフォームの存在は、SMS通知に加えて、クラスのスケジュールに関する情報を提供し、その変更について通知する少なくとも1つのボットの作成をすぐに提案しました。

プラットフォームの機能によって明らかにされたこれらの要件の下で、iframeアプリケーションを開発することにしました。

「このようなものになるだろう」と示すような実装の実用例はありませんでした。 したがって、コンセプトの小さなスケッチが作成されました。 bitrix24でのプロジェクトの実装をどのように見るかを簡単に説明するドキュメントをまとめました。 これは開発の決定に重要な役割を果たしました。

付録24

要件とツールを定義したので、開発プロセス自体を検討できます。

説明の順序は次のとおりです。

• エンティティの説明
  
• アプリケーション構造の説明
  
• 管理インターフェース
  
• 教師インターフェース
  
• 学生インターフェース
  
• 使用される技術とプロセスのスタック
  

さあ、行こう！

キーエンティティ

前に言ったように、3つの個別のエンティティがあります。 機能するウェブサイト、bitrix CRMシステム、および開発予定のiframeアプリケーション。 これらのエンティティに含まれるデータは、次のマインドマップとして概略的に表すことができます。



これらの異種エンティティを「友達に」し、データの整合性の問題を解決する必要がありました。

すべてのディレクトリのデータベースとスケジュール自体は既にサイトで作成および操作されているため、このデータをbitrix24アプリケーションで取得できるように、REST APIを単純に実装することにしました。

Bitrix24サイドソリューション構造

ユーザーロールごとに個別のアプリケーションが実装されました。 スキームの下で、これが行われた理由を説明します。



アプリケーションが1つの場合、アクセス分散ロジックを実装する必要があるため、この方法で機能を分散することにしました。 学生は成績のあるジャーナルにアクセスする必要はありません。教師はスケジュールを管理する必要はありません。 一般に、これはひどいタスクではありませんが、すぐに使用できるユーザーグループのレベルでアプリケーションのアクセスポリシーを構成できる環境を使用します。 さらに、bitrix24を開発プラットフォームと見なします。既存の機能を使用しないでください。

現在、アプリケーションには4つの部門があります：ポータル管理者、教師、生徒、チャットボット。

バックエンド構造

バックエンドレベルで3つのアプリケーションのスキームを実装するために、次の要件を作成しました。

1. 各アプリケーションには、独自の一意のURL（エントリポイント）が必要です
   
2. 各アプリケーションには一意の識別子とアクセスキーが必要です（アプリケーションの作成時にbitrix24によって生成され、作業時に必要です）
   
3. 単一のGitリポジトリを使用する
   
4. 3つのアプリケーションすべてに共通のデータベースが必要です（3つのアプリケーションはすべて同じエンティティで動作します）
   

その結果、次のものが得られました。

1. 各アプリケーションのコードは、個別の仮想ホストディレクトリにあります
   
2. すべての特徴的な構成情報は、各アプリケーションの.envファイルに保存されます
   
3. gitでは、管理アプリケーションのみをホストしています。 学生および教師のアプリケーションホストには、バックエンドのフレームワークとして使用されるlaravelを「取得」するための最小限のエンティティが含まれます。 同時に、メインホストに格納され、すべてのアプリケーションの作業に必要なエンティティは、シンボリックリンクによって単にリンクされます。 各アプリケーションには独自のバンドルjsとcssがあり、これも管理アプリケーションディレクトリにあり、対応するアプリケーションのエントリポイントを介して接続されています。
   
4. 3つのアプリケーションすべてに1つのデータベースがあります。 移行とシードとの競合が発生しないように、データベースディレクトリは、生徒および教師のホストから管理者アプリケーションのgitの下のディレクトリにリンクされます。
   

管理インターフェース

スケジュールを操作する

最初に、要件を詳述する前に、本格的なアプリケーションの実装を決定する前に、タスクはスケジュール管理システムを変更することでした。サイト側の実装により、スケジューリングの作業が地獄のような苦痛になり、多くの時間がかかりました。

実際、これはbitrix情報ブロックインターフェイスを介してデータベースにレコードを追加/編集しています
つまり、アクティビティをスケジュールするには、テーブルインターフェイスで要素を作成する必要がありました。



より便利な解決策を探す過程で、私たちは考えました-スケジュールのように見えるインターフェースでスケジュールを編集するよりも何が便利だろうか？

機能的なプロトタイプを開発しました



そして、色、ドラッグアンドドロップ、サイドバー、通知を追加しました。 そして彼らはフクロウを描きました 。

アプリケーションのより詳細なビューのために、ソリューションの機能の一部を表示する小さなスクリーンキャストを記録しました。



実装されている機能：

• 作成\編集\削除レッスン
  
• スケジュールグリッドでの勤務地の変更
  
• 1ペアのフレームワークでのペアクラスの作成
  

要件には、スケジュールが変更された場合の通知の送信も含まれていました。 と言われています-実装されています。 通知はチャットボット（モバイルアプリケーションでも利用可能）によってsmsゲートウェイ経由で配信され、グループのニュースフィードに投稿されます（もちろん）。

デフォルトでは、グループが変更された生徒と教師に通知が送信されますが、管理者は受信者のリストを選択することもできます。 通知自体のテキストはテンプレートに従って生成されますが、簡単に変更できます。

仕組み

大量のメッセージを送信するプロセスは遅延する可能性があるため、 ギアマンタスクマネージャーに基づいて通知を送信する実装をコンパイルしました。 つまり、バックグラウンドで起動された複数のワーカーがいて、SMSでもチャットボットメッセージでも、送信タスクを受け入れる準備が常に整った状態にあります。

だから我々は得た：

• リソースの制御 -リソースとタスクの面で余裕がある限り「ぶらぶら」している
  
• 作業速度 -「パラレル」実行により、大量のメッセージを迅速に処理できます。
  
• メッセージ送信の制御 -配信エラーの場合、タスクのステータスを追跡し、たとえば再送を開始できます
  

CRUD接続

管理インターフェイスで解決したもう1つの問題は、Bitrixの教師とグループを含む教師とサイトのグループのマッピングです。 それは社会的です。 bitrix24グループは、生徒が見ているものを教師に表示するスケジュールによって決定されます。 つまり、APIのデータであり、bitrix24からのデータに従ってフィルターします。 これを行うために、これらの依存関係が付加された特別なCRUDインターフェイスを実装しました。

管理者は、接続を作成するために、サイトで既に利用可能な教師から教師を選択できます



または、メール通知を送信して新しい人を招待します

ディレクトリを操作する

また、管理者のタスクには参照データの管理が含まれ、そこからスケジュールが「収集」されます-科目、教師、教室。 一般に、この作業はサイトの管理インターフェイスで実行できますが、管理者が単一の環境にいるために、インターフェイスをアプリケーションに直接実装しました。

通知

さまざまなイベントについてユーザーに通知するために、アプリケーションは4種類の約25の通知を使用します。

• 成功
  
• 警告
  
• 保留中
  
• エラー
  

通知を表示する1つの「配置」-右上隅に制限することもできますが、残念ながら（または幸運にも）組み込みiframeアプリケーションの制限に遭遇しました。

bitrixポータルのIframeブロックの標準の高さは約800pxであり、そのようなスクラップに適切なものを収めることはできませんでした。 この値を超えると、iframeブロックには独自の垂直スクロールバーがあります。 1ページに2つのスクロールバーがありますか？ -「多すぎる！」。 幸いなことに、bitrixライブラリには組み込みのfitWindowメソッドがあり、コンテンツのサイズに応じてiframeブロックを拡大します。

2番目のスクロールを取り除きましたが、固定位置を使用する可能性もありました。 そのため、開始のソースの横に通知を追加しました。

そして、それらは次のようになります。



教師レコードの保存エラー



アイテム名を保存しました

重要なものを削除しようとしています



長いリクエストでは、ボタンは保留状態を表示します

このような通知を使用すると、アプリケーションがより活発になり、応答性が向上するため、ユーザーの知覚に非常に良い効果があります。

教師インターフェース

教師のために、3つの主要な部分で構成されるアプリケーションを開発しました：クラスのスケジュール、ジャーナル、および学生の成績。

[クラススケジュール]ページで、教師は自分のスケジュールを表示し、自分が教えているグループによるフィルターを使用できます。 さらに、教師はスケジュールエントリ（講義、セミナー、実験室作業、練習、宿題など）に基づいて、特定のタイプのジャーナルエントリを無制限に作成できます。

ジャーナルでは、教師は成績、生徒の出席、宿題に関する情報を記録できます。

クラスの作成、削除、編集、および学生とのチャットは次のようになります。

学生インターフェース

学生が知る必要がある最も重要なことは、授業のスケジュール、学業成績、宿題です。 管理者および教師のインターフェースとの類推により、クラスのスケジュールを表示するページが作成されました。 外観がわずかに変更され、余分な機能が削除されました。



パフォーマンスページで、学生は現在の成績と科目の平均点を見ます。 セメスターフィルターもあります。

チャットボット

当分の間、スケジュールの変更に関するメッセージを送信し、要求に応じてスケジュールグリッドを送信するという簡単な任務をチャットボットに割り当てました。 特定の日または週全体のスケジュールをリクエストできます。 ポータルのチャットルームで利用可能なサービスとしてのチャットボットは、モバイルバージョンのポータルで自動的に利用可能です-非常に便利です。 したがって、モバイルデバイスからスケジュールに簡単にアクセスできます。



このような画像をチャットボットアイコンとして使用することは非常に魅力的でした



しかし、皮肉なことを考えて、そうしませんでした。

品質管理

アプリケーションを使用して作業するとき、作業の結果、アプリケーションエラー、およびユーザーの問題にjeします。

カーディオセキュリティとアプリケーションの高品質な動作を確保するために、一連の対策を適用します。

組み立てとテスト

開発テストと運用には3つの独立したサーバーを使用します。

開発中のgit-flowモデルがあります。

自動テストでは、 codeceptionを使用し、サイトからユーザースクリプトとAPIデータをテストします。

ステージングとプロダクションでアプリケーションをビルドするには、gitlab-ciを使用して、必要なアプリケーションディレクトリにファイルを配置し（実際にはそれらのいくつかを取得しました、上記を参照）、フロントエンドnpm run build、composer、およびauto testsアセンブリを開始します。

エラー制御

どのようにすべてをテストでカバーしようとしても、それは不可能です。常に例外的な状況があります。 いずれにしても、間違いは避けられません。 回避できない場合は、どうにかして制御できますか？

おそらく、サーバーでエラーが突然発生した場合、ログに書き込まれ、その後診断できるという事実に慣れているでしょう。 しかし、フロントエンドで発生する間違いをどうするか？ クライアントで起こることはすべて彼にあります。 エラーが十分に重大である場合、怒っている顧客のフィードバックを通じてそれについて知ることができます。 これは明らかに私たちの方法ではありません。

アプリケーションの生産プロセス中に発生する可能性のあるエラーをキャッチするために、このサービスhttps://sentry.ioを使用し、ひどく楽しんでいます 。 このサービスは、クライアントエラーとサーバーエラーの両方を構築します。 すべてのエラーが追跡され、解決する必要があります。

ボーナスとして、スラックの統合を設定して、先例の瞬間にプロジェクトチャネルに通知が表示されるようにします。 これにより、お客様がサポートシステムでチケットを作成する前にエラーを検出し、状況が重大な場合は迅速に対応できます。

モニタリング

Zabbixは 、マシンの生産ステータスを追跡するために使用されます。 すべての基本的なマシンパラメータは、可用性からリソース使用まで監視されます。

診断

サイトポータルリンクを形成し、スケジュールを作成すると、データの整合性に違反する競合が発生する可能性があります。 たとえば、1人の教師が誤って同じ日に、同じカップルに複数のクラスを割り当てられている場合があります。

人間はロボットではありません。 あなたは間違いなくすべてを追跡することはできません。 このような問題を解決するために、「コントロール」診断画面を収集しました。この画面では、チェックのリストとその結果をチェックリストの形式で配置しました。

診断の仕組み

スケジュールを作成するときなど、問題を引き起こす可能性がある状況で診断を実行すると便利です。 すぐに確認することは可能ですが、より柔軟でスケーラブルなソリューションを適用しました。

チェックリストを拡張可能として計画しました。 一部の操作は、非常にリソースを消費します。 gearmanを使用して、診断でアプリケーションの動作をブロックしないように、「潜在的に危険な」イベントが発生し、管理者アプリケーションが最初に起動されたときに、検証タスクをキューに送信します。

チェックの1つでエラーが発生した場合、制御セクションに移動することを強く推奨して「悪のロボット」を起動します。



開発者がスケジュールの競合などを解決できない場合があるため、「アセンブリ」テストで診断を開始しませんでした。

仕事で使用したもの

技術的な観点から見ると、プロジェクト全体が非常に複雑であるため、テクノロジーの選択に徹底的に取り組みました。 サーバープログラミング言語として、MySQL DBMSと組み合わせてPHPを使用することにしました。 このバンドルは、ウェブ開発の世界で非常に人気があり、さらに私たちのチームによく知られています。

このプロジェクトはCRM Bitrix 24の使用に基づいているため、多くはポータルAPIの使用に関係しています。 多くの場合、さまざまなメソッドの呼び出しが使用されるため、この部分を最大限に簡素化する必要があります。 この目的のために、便利なオブジェクトアプローチを提供するbitrix24-php-sdkを使用することにしました。 同時に、このライブラリの開発にも少し参加しています。

2017年にネイティブPHPを作成することは、特にこのサイズのプロジェクトにとって最良の選択肢とはほど遠いものです。 したがって、フレームワークを選択する必要がありました。 要件のうち、MVC、ORM、移行およびシードの存在は、キューを操作します。 多くのLaravel、YII2、Zend、Phalconなど、ほとんど知られていないフレームワークがこれらの要件に適しています。 私たちのチームは彼と仕事をした経験が豊富だったので、Laravelを選択することにしました。

フロントエンドの観点からは、優れた機器を選択することも重要でした。 React / Redux / React Routerバンドルに注目しました。

Reactの中心にはコンポーネントアプローチがあり、これは私たちに非常に適しています。 1つのコンポーネントを実装してから、アプリケーションの複数の場所で再利用すると便利です。

したがって、たとえば、クラススケジュールを表示するためのコンポーネントを使用していました。 一般的には、生徒と管理者および教師の両方で同じです。 すべての特徴的な機能は、コンポーネントのプロパティを通じて適切に構成されます。

また、Reactには巨大なコミュニティと多数の異なる実装コンポーネントがあります。 react dndコンポーネントは、クラス転送メカニズムの実装に大いに役立ちました。

スタイルを記述するために、Lessプリプロセッサを使用しました。これは、階層構造、不純物、および変数を使用することでCSSコードの行数を大幅に削減します。

プロジェクトWebpackのアセンブリを担当します。 実際、コレクターの選択はそれほど基本的ではありませんでした。特別な瞬間や要件はなかったからです。

おわりに

プロジェクトに取り組んで、1つの投稿で説明するのが難しい経験を得ました。 個別の問題の開示は、別々の出版物で行う方が合理的です。

近い将来のコンテンツプランがあります。特に、作業の過程で形成したlaravel-react-bitrix24 APIバンチの定型文を伝え、共有したいと考えています。 いくつかのポイントがコミュニティへの関心を喚起し、コメントの一部として明らかにできない場合は、新しい資料に関する知識と経験を喜んで共有します。