第一部分，读者将简要了解内部2GIS产品的出现以及数据传递系统从几个脚本到完整的应用程序的演进的简要历史。今天，我将告诉您一个9年前始于DublGIS的故事。
我刚在那儿找到工作。 我必须处理用于从大型内部系统为我们的外部产品导出数据的模块。 在本文中，我想与大家分享我们如何将这个整体分成几个部分，一个怪物如何生成数十种产品，以及所有这些产品和项目如何在数据级之间相互集成。
我必须说，这只是一篇评论文章，没有任何技术细节。 该技术将在第二部分中，其中我们将讨论数据导出。 在此期间，只有浅表阅读而没有涉及技术的表述。
走吧 2010年 那时2GIS仍然是DoubleGIS，从外部产品来看，有台式机版本和原始在线版本以及PDA版本。 内部由面向PC版用户的更新交付系统和一个名为DGPP的怪兽组成，该怪兽结合了用于编辑组织和地图目录，CRM以及将数据导出到最终产品的工具。 该数据库位于Firebird中。 该系统是分散的。 每个城市都有自己的设施和数据库。 通过文件导出/导入提供了原始集成。 基本上，仅此而已。
DGPP本身是带有一组VBA脚本的C ++应用程序。 最初，第三方办公室为DublGIS开发了该系统，然后公司才随着时间的推移在自己的屋顶下进行了系统开发，从而形成了自己的研发中心。 开发DGPP变得越来越困难。
而这正是DublGIS快速发展的时代。 新的城市正在开放。 正在准备智能手机的移动版本。 出现了新功能。 正在开发一种广告模型。 通常，需要进行大量更改，并且需要快速完成。
我们开始将DGPP分解为几部分的第一件事是导出。 我们将其拉到一个单独的应用程序中，该应用程序是Windows服务，带有WPF的枪口。 同时，正在进行一项新的CRM的工作。 为了节省时间，Microsoft Dynamics CRM被选为基本平台。
至于导出，您只需要学习如何从Firebird中提取数据并提取所有用于从VBA脚本准备数据的逻辑即可。 此外，还有一些用于实现数据传输的算法。 他们必须改写为利器。
这里值得一提。 我们的桌面DoubleGIS使用了特殊的二进制格式的数据，该格式由包装在COM对象中的C ++库准备。 然后使用它是很合逻辑的，只需将其作为对项目的引用即可。 这不是最好的解决方案，但是我稍后会讨论。
随着时间的流逝，我们推出了移动版本和新的CRM。 一种新的外部产品即将面世-公共API 2GIS。 从DGPP开始，他们已经开始隔离子系统，以与代号为InfoRussia的组织目录一起使用。
在导出过程中，有必要从两个系统读取广告数据：旧的DGPP和新的CRM。 此外，CRM的实施正在逐步进行，也就是说，到目前为止，在某些城市中仅剩下DGPP，而在另一些城市中，DGPP同时使用目录和地图以及带有商业信息的CRM。 此外，从长远来看，历时数月的InfoRussia发行令人眼前一亮。
新系统不仅从外观上引入了复杂性。 他们改变了部署的概念。 与遍布每个城市的分散DGPP不同，这些系统是集中式的，每个系统都有自己的丰满DBMS。 另外，他们需要交换数据。
为了解决此问题，我们实施了企业服务总线（ESB）。 那时，几乎没有成熟的解决方案可以确保满足我们的一些重要功能要求：传输XML的能力，消息的顺序和传递的保证。 然后，我们选择了SQL Server Broker，该组件开箱即用地提供了所需的一切。 没错，他的送货速度相当中等，但是那时她对我们很满意。
最后一步是发布名为Fiji的地图服务。 他将自己的数据部分上传到了公共汽车。 这涉及目录和分类器。 可以通过Rest API从他那里获取地理数据，Rest API也由
WPF编写的斐济客户端本身使用。
在这种体系结构中，出口至关重要。 通过它，所有数据流都合并到一个存储库中，并分发给最终产品和我们的用户。
此外，它只是冰山的一小部分。 内部流程的自动化，新要求和新功能的出现导致大量产品的出现。 有必要进行分析，使用用户反馈，引入新的销售模型和新的商业产品，开发搜索，运输算法以及通常是外部产品。
一方面，导出具有大量的数据提供者，另一方面，具有大量的消费者，每个消费者都希望以特定的形式接收数据并通过特殊的准备算法来运行它。
然后我的故事结束了。
在文章的第二部分，我将向您介绍Export，并分享他如何在所有这些变化中幸免。 不会有故事，但是在解决特定任务列表时将应用特定方法。