Bagian satu, di mana pembaca akan berkenalan dengan sejarah singkat tentang kemunculan produk 2GIS internal dan evolusi sistem pengiriman data dari beberapa skrip ke aplikasi yang lengkap.Hari ini saya akan menceritakan sebuah kisah yang dimulai 9 tahun yang lalu di DublGIS.
Saya baru saja mendapat pekerjaan di sana. Saya harus berurusan dengan modul untuk mengekspor data dari sistem internal besar untuk produk eksternal kami. Dan dalam artikel ini saya ingin berbagi dengan Anda bagaimana kami membagi monolit ini menjadi beberapa bagian, bagaimana satu monster menghasilkan beberapa produk, dan bagaimana semua produk dan proyek ini terintegrasi pada tingkat data di antara mereka sendiri.
Saya harus mengatakan bahwa ini hanya artikel ulasan tanpa rincian teknis. Tekniknya akan di bagian kedua, di mana kita akan berbicara tentang ekspor data. Sementara itu, hanya bacaan ringan tanpa matan dengan penyebutan teknologi yang dangkal.
Ayo pergi. Jauh 2010 Kemudian 2GIS masih berupa tabung DoubleGIS, dari produk eksternal ada versi desktop dan online primitif dan versi untuk PDA. Dan bagian dalam terdiri dari sistem pengiriman pembaruan untuk pengguna versi PC kami dan monster yang disebut DGPP, yang menggabungkan alat untuk mengedit direktori organisasi dan peta, CRM dan mengekspor data ke produk akhir. Basis data ada di Firebird. Sistem ini didesentralisasi. Setiap kota memiliki instalasi sendiri dan database sendiri. Integrasi primitif diberikan melalui ekspor / impor file. Dan dalam hal ini, pada umumnya, itu saja.
DGPP sendiri adalah aplikasi C ++ dengan sekumpulan skrip VBA. Awalnya, kantor pihak ketiga mengembangkan sistem ini untuk DublGIS, dan hanya dengan waktu perusahaan dapat mengembangkan sistem di bawah atapnya, membentuk R&D sendiri. Mengembangkan DGPP menjadi semakin sulit.
Dan ini adalah masa perkembangan pesat DublGIS. Kota-kota baru dibuka. Versi mobile untuk smartphone sedang dipersiapkan. Fitur baru muncul. Model iklan berkembang. Secara umum, sejumlah besar perubahan diperlukan, dan itu perlu dilakukan dengan cepat.
Hal pertama yang kami mulai membongkar DGPP menjadi potongan-potongan adalah ekspor. Kami menariknya ke dalam aplikasi terpisah, yang merupakan layanan windows dengan moncong di WPF. Secara paralel, pekerjaan sedang dilakukan pada CRM baru. Untuk menghemat waktu pada waktu itu, Microsoft Dynamics CRM dipilih sebagai platform dasar.
Sedangkan untuk ekspor, Anda hanya perlu mempelajari cara mengekstrak data dari Firebird dan mengeluarkan semua logika untuk menyiapkan data dari skrip VBA. Selain itu, ada beberapa algoritma untuk transportasi data yang diterapkan pada plus. Mereka harus ditulis ulang menjadi benda tajam.
Di sini perlu diperhatikan satu hal. Desktop DoubleGIS kami menggunakan data dalam format biner khusus, yang disiapkan oleh pustaka C ++ yang dibungkus dengan objek COM. Dan kemudian cukup logis untuk menggunakannya, cukup menghubungkan sebagai referensi ke proyek. Bukan solusi terbaik, tetapi saya akan membicarakannya nanti.
Seiring berjalannya waktu, kami meluncurkan versi seluler dan CRM baru. Produk eksternal baru telah muncul di cakrawala - API 2GIS publik. Dan dari DGPP mereka sudah mulai mengisolasi subsistem untuk bekerja dengan direktori organisasi dengan nama sandi InfoRusia.
Dalam ekspor, menjadi perlu untuk membaca data iklan dari dua sistem: DGPP lama dan CRM baru. Terlebih lagi, implementasi CRM berjalan secara bertahap, yaitu di beberapa kota, sejauh ini hanya DGPP yang tersisa, sementara di yang lain DGPP bekerja secara bersamaan dengan sebuah direktori dan peta dan CRM dengan informasi komersial. Selain itu, dalam jangka panjang rilis InfoRussia, yang berlangsung selama beberapa bulan, bersinar.
Sistem baru memperkenalkan kompleksitas tidak hanya oleh penampilannya. Mereka mengubah konsep penempatan. Tidak seperti DGPP terdesentralisasi yang berdiri di setiap kota, sistem ini terpusat, masing-masing dengan DBMS yang montok. Selain itu, mereka perlu bertukar data.
Untuk mengatasi masalah ini, kami menerapkan Bus Layanan Perusahaan (ESB) kami. Pada saat itu, praktis tidak ada solusi matang yang akan memastikan terpenuhinya beberapa persyaratan fungsional penting bagi kami: kemampuan untuk mengirimkan XML, urutan pesan, dan jaminan pengiriman. Kemudian kami menetap di SQL Server Broker, yang memberikan semua yang diperlukan dari kotak. Benar, dia memiliki kecepatan pengiriman yang agak biasa-biasa saja, tetapi pada saat itu dia cukup senang dengan kami.
Langkah terakhir adalah merilis layanan peta yang disebut Fiji. Dia mengunggah sebagian data ke bus. Ini menyangkut direktori dan pengklasifikasi. Geodata dapat diambil darinya melalui API Istirahat, yang juga digunakan oleh
klien Fiji itu sendiri
, yang ditulis dalam WPF .
Dalam arsitektur ini, ekspor adalah pusat. Melalui itu, semua aliran data bergabung ke dalam satu repositori dan didistribusikan ke produk akhir dan pengguna kami.
Selain itu, itu hanya sebagian kecil dari gunung es. Otomatisasi proses internal, munculnya persyaratan baru dan fitur-fitur baru menyebabkan munculnya sejumlah besar produk. Itu diperlukan untuk melakukan analitik, bekerja dengan umpan balik pengguna, memperkenalkan model penjualan baru dan produk komersial baru, mengembangkan pencarian, algoritma transportasi dan, secara umum, produk eksternal.
Di satu sisi, ekspor memiliki sejumlah besar penyedia data, dan di sisi lain, sejumlah besar konsumen, yang masing-masing ingin menerima data dalam bentuk tertentu dan menjalankannya melalui algoritma persiapan khusus.
Dan kemudian kisah saya berakhir.
Di bagian kedua artikel ini saya akan memberi tahu Anda tentang Ekspor dan membagikan bagaimana dia selamat dari semua perubahan ini. Tidak akan ada cerita, tetapi akan ada pendekatan spesifik yang telah kami terapkan dalam menyelesaikan daftar tugas tertentu.