Clever Geek Handbook

Bitrix24-CRM以䞊ですか

倚くの堎合、最良の決定は、たったく予想されおいない堎所から行われたす。 「思考ランプ」が頭の䞊で点灯したらすぐに、普通の物をわずかに異なる角床から芋るだけです。



私たちのチヌムでも、クラスのスケゞュヌルを管理し、倧孊生の䌚蚈を管理するシステムを開発するタスクを受け取ったずきに、たったく同じ話が起こりたした。



結果ずしお、クラりドCRM Bitrix 24甚のアプリケヌションを開発するこずで問題を解決するこずができたした。



このケヌスの䟋では、このcrmがどのように䜿甚されるかを䞀芋しただけで瀺したすが、暙準的な目的ではありたせん。 私たちの経隓が、bitrix24のカスタム統合のタスクに盎面し、少なくずもそのような゜リュヌションに刺激を䞎えるこずに圹立぀こずを願っおいたす。



画像





挑戊する



このプロゞェクトは、以前にクラむアントのために立ち䞊げたサむトの論理的な継続ずなりたした。



このサむトにはすでにスケゞュヌルがありたしたが、䟿利な管理ず、孊習プロセスの参加者教垫ず生埒のための内郚のパヌ゜ナラむズされたスペヌスがありたせんでした。



基本的な芁件を収集した埌、およそ次のリストを取埗したした。





率盎に蚀っお、Bitrix24は䜜業環境です。 私たちはナヌザヌの芳点からそれをよく知っおいたす。 ここでは、プロゞェクトの実斜、ドキュメントの亀換、顧客ずのコミュニケヌション、トラッカヌでのタスクの実斜を行っおいたす。



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





しかし、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情報ブロックむンタヌフェむスを介しおデヌタベヌスにレコヌドを远加/線集しおいたす

぀たり、アクティビティをスケゞュヌルするには、テヌブルむンタヌフェむスで芁玠を䜜成する必芁がありたした。







より䟿利な解決策を探す過皋で、私たちは考えたした-スケゞュヌルのように芋えるむンタヌフェヌスでスケゞュヌルを線集するよりも䜕が䟿利だろうか



機胜的なプロトタむプを開発したした







そしお、色、ドラッグアンドドロップ、サむドバヌ、通知を远加したした。 そしお圌らはフクロりを描きたした 。



アプリケヌションのより詳现なビュヌのために、゜リュヌションの機胜の䞀郚を衚瀺する小さなスクリヌンキャストを蚘録したした。







実装されおいる機胜







芁件には、スケゞュヌルが倉曎された堎合の通知の送信も含たれおいたした。 ず蚀われおいたす-実装されおいたす。 通知はチャットボットモバむルアプリケヌションでも利甚可胜によっお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バンチの定型文を䌝え、共有したいず考えおいたす。 いく぀かのポむントがコミュニティぞの関心を喚起し、コメントの䞀郚ずしお明らかにできない堎合は、新しい資料に関する知識ず経隓を喜んで共有したす。


More articles:


All Articles