业务应用程序最重要的要求是什么? 一些最重要的任务如下:
- 轻松更改/调整应用程序逻辑以适应不断变化的业务任务。
- 与其他应用程序轻松集成。
“定制和支持”部分简要描述了 1C 中如何解决第一个任务
整合任务
集成任务可以不同。 为了解决一些问题,简单的交互式数据交换就足够了——例如,将员工名单传输到银行以发放工资塑料卡。 对于更复杂的任务,可能需要完全自动化的数据交换,可能参考外部系统的业务逻辑。 有些任务本质上是专门的,例如与外部设备(例如零售设备、移动扫描仪等)或与传统或高度专业化的系统(例如与 RFID 标签识别系统)集成。 为每项任务选择最合适的集成机制极其重要。
与 1C 的集成选项
实现与 1C 应用程序集成的方法有多种;选择哪一种取决于任务的要求。
- 基于实施
整合机制 平台提供的1C应用端自己专门的API(例如,一组Web或HTTP服务,将调用第三方应用程序与1C应用程序交换数据)。 这种方法的优点是 API 能够抵抗 1C 应用程序端实现的变化。 该方法的特殊性在于,需要更改标准 1C 解决方案的源代码,在迁移到新版本的配置时合并源代码可能需要付出努力。 在这种情况下,一个新的渐进式功能可以拯救 -配置扩展 。 本质上,扩展是一种插件机制,允许您在不更改应用程序解决方案本身的情况下创建应用程序解决方案的附加内容。 将集成 API 移至配置扩展中将使您能够避免在迁移到新版本的标准解决方案时合并配置时遇到的困难。 - 使用平台集成机制提供对应用程序对象模型的外部访问,并且不需要修改应用程序或创建扩展。 这种方法的优点是无需更改 1C 应用程序。 减号 - 如果 1C 应用程序已得到改进,则集成应用程序可能需要改进。 这种方法的一个示例是使用 OData 协议进行集成,在 1C:Enterprise 平台一侧实现(更多相关信息请参见下文)。
- 使用在标准 1C 解决方案中实施的现成应用协议。 1C 和合作伙伴的许多标准解决方案基于平台提供的集成机制来实现自己的应用程序协议,专注于特定任务。 使用这些机制时,不需要在1C应用程序端编写代码,因为我们使用应用程序解决方案的标准功能。 在1C应用端,我们只需要进行一定的设置即可。
1C:企业平台中的集成机制
导入/导出文件
假设我们面临一个 1C 应用程序和任意应用程序之间双向数据交换的任务。 例如,我们需要在 1C 应用程序和任意应用程序之间同步产品列表(Nomenclature 目录)。
为了解决这个问题,您可以编写一个扩展,将 Nomenclature 目录下载到某种格式(文本、XML、JSON...)的文件中,并可以读取该格式。
该平台实现了一种直接通过 WriteXML/ReadXML 全局上下文方法以及使用 XDTO(XML 数据传输对象)辅助对象以 XML 形式序列化应用程序对象的机制。
1C:Enterprise 系统中的任何对象都可以序列化为 XML 表示形式,反之亦然。
该函数将返回对象的 XML 表示形式:
Функция Объект_В_XML(Объект)
ЗаписьXML = Новый ЗаписьXML();
ЗаписьXML.УстановитьСтроку();
ЗаписатьXML(ЗаписьXML, Объект);
Возврат ЗаписьXML.Закрыть();
КонецФункции
使用 XDTO 将 Nomenclature 目录导出到 XML 将如下所示:
&НаСервере
Процедура ЭкспортXMLНаСервере()
НовыйСериализаторXDTO = СериализаторXDTO;
НоваяЗаписьXML = Новый ЗаписьXML();
НоваяЗаписьXML.ОткрытьФайл("C:DataНоменклатура.xml", "UTF-8");
НоваяЗаписьXML.ЗаписатьОбъявлениеXML();
НоваяЗаписьXML.ЗаписатьНачалоЭлемента("СправочникНоменклатура");
Выборка = Справочники.Номенклатура.Выбрать();
Пока Выборка.Следующий() Цикл
ОбъектНоменклатура = Выборка.ПолучитьОбъект();
НовыйСериализаторXDTO.ЗаписатьXML(НоваяЗаписьXML, ОбъектНоменклатура, НазначениеТипаXML.Явное);
КонецЦикла;
НоваяЗаписьXML.ЗаписатьКонецЭлемента();
НоваяЗаписьXML.Закрыть();
КонецПроцедуры
通过简单修改代码,我们将目录导出为JSON。 产品将被写入数组; 为了多样化,这里是语法的英文版本:
&AtServer
Procedure ExportJSONOnServer()
NewXDTOSerializer = XDTOSerializer;
NewJSONWriter = New JSONWriter();
NewJSONWriter.OpenFile("C:DataНоменклатура.json", "UTF-8");
NewJSONWriter.WriteStartObject();
NewJSONWriter.WritePropertyName("СправочникНоменклатура");
NewJSONWriter.WriteStartArray();
Selection = Catalogs.Номенклатура.Select();
While Selection.Next() Do
NomenclatureObject = Selection.GetObject();
NewJSONWriter.WriteStartObject();
NewJSONWriter.WritePropertyName("Номенклатура");
NewXDTOSerializer.WriteJSON(NewJSONWriter, NomenclatureObject, XMLTypeAssignment.Implicit);
NewJSONWriter.WriteEndObject();
EndDo;
NewJSONWriter.WriteEndArray();
NewJSONWriter.WriteEndObject();
NewJSONWriter.Close();
EndProcedure
然后剩下的就是将数据传输给最终消费者。 1C:Enterprise 平台支持主要互联网协议 HTTP、FTP、POP3、SMTP、IMAP,包括其安全版本。 您还可以使用 HTTP 和/或 Web 服务来传输数据。
HTTP 和 Web 服务
1C应用程序可以实现自己的HTTP和Web服务,也可以调用第三方应用程序实现的HTTP和Web服务。
REST接口和OData协议
从8.3.5版本开始,1C:Enterprise平台可以自动
所以,像这样的 URL http://<сервер>/<конфигурация>/odata/standard.odata/Catalog_Номенклатура 将以 XML 格式返回 Nomenclature 目录的内容 - 条目元素的集合(为简洁起见,省略了消息标题):
<entry>
<id>http://server/Config/odata/standard.odata/Catalog_Номенклатура(guid'35d1f6e4-289b-11e6-8ba4-e03f49b16074')</id>
<category term="StandardODATA.Catalog_Номенклатура" scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme"/>
<title type="text"/>
<updated>2016-06-06T16:42:17</updated>
<author/>
<summary/>
<link rel="edit" href="Catalog_Номенклатура(guid'35d1f6e4-289b-11e6-8ba4-e03f49b16074')" title="edit-link"/>
<content type="application/xml">
<m:properties >
<d:Ref_Key>35d1f6e4-289b-11e6-8ba4-e03f49b16074</d:Ref_Key>
<d:DataVersion>AAAAAgAAAAA=</d:DataVersion>
<d:DeletionMark>false</d:DeletionMark>
<d:Code>000000001</d:Code>
<d:Description>Кондиционер Mitsubishi</d:Description>
<d:Описание>Мощность 2,5 кВт, режимы работы: тепло/холод</d:Описание>
</m:properties>
</content>
</entry>
<entry>
<id>http://server/Config/odata/standard.odata/Catalog_Номенклатура(guid'35d1f6e5-289b-11e6-8ba4-e03f49b16074')</id>
<category term="StandardODATA.Catalog_Номенклатура" scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme"/>
...
通过将字符串“?$format=application/json”添加到 URL,我们可以获取 JSON 格式的 Nomenclature 目录的内容(URL 形式为 http://<сервер>/<конфигурация>/odata/standard.odata/Catalog_Номенклатура?$format=application/json ):
{
"odata.metadata": "http://server/Config/odata/standard.odata/$metadata#Catalog_Номенклатура",
"value": [{
"Ref_Key": "35d1f6e4-289b-11e6-8ba4-e03f49b16074",
"DataVersion": "AAAAAgAAAAA=",
"DeletionMark": false,
"Code": "000000001",
"Description": "Кондиционер Mitsubishi",
"Описание": "Мощность 2,5 кВт, режимы работы: тепло/холод"
},{
"Ref_Key": "35d1f6e5-289b-11e6-8ba4-e03f49b16074",
"DataVersion": "AAAAAwAAAAA=",
"DeletionMark": false,
"Code": "000000002",
"Description": "Кондиционер Daikin",
"Описание": "Мощность 3 кВт, режимы работы: тепло/холод"
}, …
外部数据源
在某些情况下,数据交换通过
数据交换机制
这种机制在 1C 实现中被积极使用,并且借助它解决的任务范围非常广泛。 这包括组织分支机构中安装的 1C 应用程序之间的数据交换、1C 应用程序与在线商店网站之间的数据交换、1C 服务器应用程序与移动客户端(使用 1C:Enterprise 移动平台创建)之间的数据交换等等。更多的。
数据交换机制中的关键概念之一是交换计划。 交换计划是1C应用平台的一种特殊类型的对象,它特别确定将参与交换的数据的组成(哪些目录、文档、寄存器等)。 交换计划还包含有关交换参与者(所谓的交换节点)的信息。
数据交换机制的第二个组成部分是变更注册机制。 该机制自动监视系统中数据的变化,这些数据必须作为交换计划的一部分传输给最终用户。 使用此机制,平台可以跟踪自上次同步以来发生的更改,并允许您最大限度地减少下一次同步会话期间传输的数据量。
数据交换使用特定结构的 XML 消息进行。 该消息包含自上次与节点同步以来已更改的数据以及一些服务信息。 消息结构支持消息编号,并允许您从接收节点接收消息已收到的确认。 这种确认包含在来自接收节点的每条消息中,以最后接收到的消息编号的形式。 编号消息使平台能够了解哪些数据已成功传输到接收节点,并通过仅传输自发送节点收到最后一条消息(带有接收节点收到的数据的收据)以来已更改的数据来避免重传。 即使在传输通道不可靠和消息丢失的情况下,这种操作方案也能确保有保证的传送。
外部元件
在许多情况下,在解决集成问题时,必须处理特定的要求,例如交互协议、数据格式,而这些要求在1C:企业平台中是没有提供的。 对于这样一系列的任务,该平台提供了
具有类似要求的任务的典型示例是将 1C 应用解决方案与零售设备(从秤到收银机和条形码扫描仪)集成。 1C:企业服务器端和客户端(包括但不限于Web客户端,以及
使用外部组件时所带来的可能性非常广泛。 您可以使用特定的数据交换协议与外部设备和系统实现交互,内置特定的算法来处理数据和数据格式等。
过时的整合机制
该平台提供了不建议在新解决方案中使用的集成机制; 保留它们是出于向后兼容性的原因,也是为了防止另一方无法使用更现代的协议。 其中之一是使用 DBF 格式文件(使用 XBase 对象的内置语言支持)。
另一种遗留的集成机制是使用 COM 技术(仅在 Windows 平台上可用)。 1C:Enterprise平台使用COM技术为Windows提供两种集成方法:自动化服务器和外部连接。 它们非常相似,但根本区别之一是,在自动化服务器的情况下,启动成熟的 1C:Enterprise 8 客户端应用程序,在外部连接的情况下,启动相对较小的进程内 COM服务器已启动。 也就是说,如果您通过自动化服务器工作,则可以使用客户端应用程序的功能并执行类似于用户交互操作的操作。 使用外部连接时,只能使用业务逻辑函数,并且它们都可以在连接的客户端执行,其中创建了进程内COM服务器,并且可以在1C:Enterprise服务器上调用业务逻辑边。
COM 技术还可用于从 1C:Enterprise 平台上的应用程序代码访问外部系统。 在这种情况下,1C 应用程序充当 COM 客户端。 但应该记住,这些机制仅在 1C 服务器在 Windows 环境中运行时才起作用。
标准配置中实施的集成机制
企业数据格式
在多种1C配置中(列举如下),基于上述平台数据交换机制,实现了与外部应用程序交换数据的现成机制,不需要更改配置的源代码(准备数据)交换是在应用程序解决方案的设置中完成的):
- 《1C:ERP企业管理2.0》
- 《复杂自动化2》
- 《企业会计》3.0版
- 《股份制企业会计》,3.0版
- 《零售》2.0 版
- 《贸易管理基础》第11版
- 贸易管理,第 11 版
- 《薪资与人事管理公司》,第 3 版
用于数据交换的格式是
1C 应用程序和第三方应用程序之间可以进行数据交换:
- 通过专用文件目录
- 通过 FTP 目录
- 通过部署在1C应用程序端的Web服务。 数据文件作为参数传递给 Web 方法
- 通过电子邮件
在通过Web服务进行交换的情况下,第三方应用程序将通过调用1C应用程序的相应Web方法来发起数据交换会话。 在其他情况下,交换会话的发起者将是 1C 应用程序(通过将数据文件放置在适当的目录中或将数据文件发送到配置的电子邮件地址)。
此外,在 1C 端,您可以配置同步发生的频率(对于通过目录和电子邮件进行文件交换的选项):
- 根据时间表(以指定的频率)
- 手动; 用户每次需要时都必须手动启动同步
确认消息
1C 应用程序保留发送和接收的同步消息的记录,并期望第三方应用程序也有相同的记录。 这允许您使用上面“数据交换机制”部分中描述的消息编号机制。
在同步期间,1C 应用程序仅传输有关自上次同步以来业务实体发生的更改的信息(以最大限度地减少传输的信息量)。 在第一次同步期间,1C应用程序会将EnterpriseData格式的所有业务实体(例如,项目参考书的项目)上传到XML文件中(因为它们对于外部应用程序来说都是“新的”)。 第三方应用程序必须处理从 1C 收到的 XML 文件中的信息,并在下一次同步会话期间,将来自 1C 的具有特定编号的消息已成功发送的信息放入发送到 1C 的文件中的特殊 XML 部分中已收到。 接收消息是向 1C 应用程序发出的信号,表明外部应用程序已成功处理所有业务实体,无需再传输有关它们的信息。 除了收据之外,来自第三方应用程序的 XML 文件还可以包含供应用程序同步的数据(例如,用于销售商品和服务的文档)。
收到回执消息后,1C应用程序将先前消息中传输的所有更改标记为已成功同步。 在下一个同步会话期间,只有对业务实体的未同步更改(创建新实体、更改和删除现有实体)才会发送到外部应用程序。
当从外部应用程序向1C应用程序传输数据时,情况相反。 外部应用程序必须相应地填写 XML 文件的接收部分,并以 EnterpriseData 格式放置要同步的业务数据。
无需握手即可简化数据交换
对于简单集成的情况,只需将第三方应用的信息传输到1C应用即可,不需要将1C应用的数据反向传输到第三方应用(例如,集成一个在线应用)商店将销售信息传输到 1C:会计),有一个通过 Web 服务工作的简化选项(无需确认),无需在 1C 应用程序一侧进行设置。
定制集成解决方案
有一个标准解决方案“1C:数据转换”,它使用平台机制在标准1C配置之间转换和交换数据,但也可用于与第三方应用程序集成。
与银行解决方案集成
标准
也有
其他
值得一提
来源: habr.com