業務應用程式最重要的要求是什麼? 一些最重要的任務如下:
- 輕鬆更改/調整應用程式邏輯以適應不斷變化的業務任務。
- 與其他應用程式輕鬆整合。
「客製化與支援」部分簡要描述了 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配置之間轉換和交換數據,但也可用於與第三方應用程式整合。
與銀行解決方案集成
規範
還有
其他
值得一提
來源: www.habr.com