1C와의 통합 방법

비즈니스 애플리케이션에 가장 중요한 요구사항은 무엇입니까? 가장 중요한 작업 중 일부는 다음과 같습니다.

• 변화하는 비즈니스 작업에 맞게 애플리케이션 로직을 쉽게 변경/적응할 수 있습니다.
• 다른 애플리케이션과 쉽게 통합됩니다.

1C에서 첫 번째 작업을 해결하는 방법은 "사용자 정의 및 지원"섹션에 간략하게 설명되어 있습니다. 이 기사; 우리는 다음 기사에서 이 흥미로운 주제를 다시 다루겠습니다. 오늘은 두 번째 과제인 통합에 대해 이야기해보겠습니다.

통합 작업

통합 작업은 다를 수 있습니다. 일부 문제를 해결하려면 간단한 대화형 데이터 교환만으로 충분합니다. 예를 들어 급여 플라스틱 카드를 발급하기 위해 직원 목록을 은행으로 전송하는 경우가 있습니다. 보다 복잡한 작업의 경우 외부 시스템의 비즈니스 로직을 참조하여 완전히 자동화된 데이터 교환이 필요할 수 있습니다. 외부 장비(예: 소매 장비, 모바일 스캐너 등)와의 통합 또는 레거시 또는 고도로 전문화된 시스템(예: RFID 태그 인식 시스템)과의 통합과 같이 본질적으로 전문화된 작업이 있습니다. 각 작업에 가장 적합한 통합 메커니즘을 선택하는 것이 매우 중요합니다.

1C와의 통합 옵션

1C 애플리케이션과의 통합을 구현하는 데는 다양한 접근 방식이 있으며, 어떤 접근 방식을 선택할지는 작업 요구 사항에 따라 다릅니다.

1. 구현 기반 통합 메커니즘플랫폼에서 제공하는 1C 애플리케이션 측의 자체 특수 API(예: 1C 애플리케이션과 데이터를 교환하기 위해 타사 애플리케이션을 호출하는 웹 또는 HTTP 서비스 세트). 이 접근 방식의 장점은 1C 애플리케이션 측면의 구현 변경에 대한 API의 저항입니다. 이 접근 방식의 특징은 표준 1C 솔루션의 소스 코드를 변경해야 한다는 것입니다. 이는 새 버전의 구성으로 이동할 때 소스 코드를 병합할 때 잠재적으로 노력이 필요할 수 있습니다. 이 경우 새로운 진보적 기능이 구출될 수 있습니다. 구성 확장. 확장은 본질적으로 애플리케이션 솔루션 자체를 변경하지 않고도 애플리케이션 솔루션에 추가 기능을 생성할 수 있는 플러그인 메커니즘입니다. 통합 API를 구성 확장으로 이동하면 새 버전의 표준 솔루션으로 이동할 때 구성을 병합할 때 발생하는 어려움을 피할 수 있습니다.
2. 애플리케이션 개체 모델에 대한 외부 액세스를 제공하고 애플리케이션 수정이나 확장 생성이 필요하지 않은 플랫폼 통합 메커니즘을 사용합니다. 이 접근 방식의 장점은 1C 애플리케이션을 변경할 필요가 없다는 것입니다. 마이너스 - 1C 애플리케이션이 개선된 경우 통합 애플리케이션에서 개선이 필요할 수 있습니다. 이 접근 방식의 예는 1C:Enterprise 플랫폼 측면에서 구현된 통합을 위해 OData 프로토콜을 사용하는 것입니다(자세한 내용은 아래 참조).
3. 표준 1C 솔루션에 구현된 기성 애플리케이션 프로토콜 사용. 1C와 파트너의 많은 표준 솔루션은 플랫폼에서 제공하는 통합 메커니즘을 기반으로 특정 작업에 초점을 맞춘 자체 애플리케이션 프로토콜을 구현합니다. 이러한 메커니즘을 사용하면 1C 애플리케이션 측에서 코드를 작성할 필요가 없습니다. 우리는 애플리케이션 솔루션의 표준 기능을 사용합니다. 1C 애플리케이션 측면에서는 특정 설정만 지정하면 됩니다.

1C:Enterprise 플랫폼의 통합 메커니즘

파일 가져오기/내보내기

1C 애플리케이션과 임의 애플리케이션 간의 양방향 데이터 교환 작업에 직면했다고 가정해 보겠습니다. 예를 들어 1C 애플리케이션과 임의 애플리케이션 간에 제품 목록(명명법 디렉터리)을 동기화해야 합니다.

이 문제를 해결하려면 명명법 디렉터리를 특정 형식(텍스트, 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 및/또는 웹 서비스를 사용하여 데이터를 전송할 수도 있습니다.

HTTP 및 웹 서비스

1C 애플리케이션은 자체 HTTP 및 웹 서비스를 구현할 수 있을 뿐만 아니라 타사 애플리케이션에서 구현된 HTTP 및 웹 서비스를 호출할 수 있습니다.

REST 인터페이스 및 OData 프로토콜

버전 8.3.5부터 1C:Enterprise 플랫폼은 자동으로 REST 인터페이스 생성 전체 애플리케이션 솔루션을 위한 것입니다. REST 인터페이스를 통해 데이터를 수신하고 수정하는 데 모든 구성 개체(디렉토리, 문서, 정보 레지스터 등)를 사용할 수 있습니다. 플랫폼은 프로토콜을 액세스 프로토콜로 사용합니다. 오데이터 버전 3.0. OData 서비스 게시는 구성 메뉴 "관리 -> 웹 서버에 게시"에서 수행되며 "표준 OData 인터페이스 게시" 확인란을 선택해야 합니다. Atom/XML 및 JSON 형식이 지원됩니다. 애플리케이션 솔루션이 웹 서버에 게시된 후 타사 시스템은 HTTP 요청을 사용하는 REST 인터페이스를 통해 이에 액세스할 수 있습니다. OData 프로토콜을 통해 1C 애플리케이션으로 작업하려면 1C 측 프로그래밍이 필요하지 않습니다.

따라서 다음과 같은 URL은 http://<сервер>/<конфигурация>/odata/standard.odata/Catalog_Номенклатура 명명법 카탈로그의 내용을 XML 형식으로 반환합니다. 즉, 항목 요소 모음입니다(간결성을 위해 메시지 제목은 생략됨).

<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"/>
...

URL에 "?$format=application/json" 문자열을 추가하면 명명법 카탈로그의 내용을 JSON 형식(형식의 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 кВт, режимы работы: тепло/холод"
}, …

외부 데이터 소스

경우에 따라 데이터 교환을 통해 외부 데이터 소스 최선의 해결책이 될 수 있습니다. 외부 데이터 소스는 읽기 및 쓰기를 위해 ODBC 호환 데이터베이스와 상호 작용할 수 있는 1C 애플리케이션 구성 개체입니다. 외부 데이터 소스는 Windows와 Linux 모두에서 사용할 수 있습니다.

데이터 교환 메커니즘

데이터 교환 메커니즘 1C:Enterprise를 기반으로 지리적으로 분산된 시스템을 생성하고 1C:Enterprise를 기반으로 하지 않는 다른 정보 시스템과의 데이터 교환을 구성하기 위한 것입니다.

이 메커니즘은 1C 구현에 적극적으로 사용되며 그 도움으로 해결되는 작업 범위는 매우 넓습니다. 여기에는 조직 지점에 설치된 1C 애플리케이션 간의 데이터 교환, 1C 애플리케이션과 온라인 상점 웹 사이트 간의 교환, 1C 서버 애플리케이션과 모바일 클라이언트 (1C:Enterprise 모바일 플랫폼을 사용하여 생성됨) 간의 데이터 교환이 포함됩니다. 더.

데이터 교환 메커니즘의 핵심 개념 중 하나는 교환 계획입니다. 교환 계획은 특히 교환에 참여할 데이터의 구성(디렉토리, 문서, 등록 등)을 결정하는 1C 애플리케이션 플랫폼의 특수한 유형의 객체입니다. 교환 계획에는 교환 참가자(소위 교환 노드)에 대한 정보도 포함됩니다.
데이터 교환 메커니즘의 두 번째 구성 요소는 변경 등록 메커니즘입니다. 이 메커니즘은 교환 계획의 일부로 최종 사용자에게 전송되어야 하는 데이터의 변경 사항을 시스템에서 자동으로 모니터링합니다. 플랫폼은 이 메커니즘을 사용하여 마지막 동기화 이후 발생한 변경 사항을 추적하고 다음 동기화 세션 동안 전송되는 데이터 양을 최소화할 수 있습니다.

데이터 교환은 특정 구조의 XML 메시지를 사용하여 발생합니다. 메시지에는 노드와의 마지막 동기화 이후 변경된 데이터와 일부 서비스 정보가 포함되어 있습니다. 메시지 구조는 메시지 번호 지정을 지원하며 메시지가 수신되었다는 확인을 수신자 노드로부터 받을 수 있습니다. 이러한 확인은 수신 노드에서 오는 각 메시지에 마지막으로 수신된 메시지 번호의 형태로 포함됩니다. 메시지에 번호를 붙이면 플랫폼은 어떤 데이터가 이미 수신 노드에 성공적으로 전송되었는지 파악하고, 수신 노드가 수신한 데이터에 대한 영수증과 함께 송신 노드가 마지막 메시지를 수신한 이후 변경된 데이터만 전송하여 재전송을 방지할 수 있습니다. 이 운영 방식은 신뢰할 수 없는 전송 채널 및 메시지 손실에도 보장된 전달을 보장합니다.

외부 구성 요소

많은 경우 통합 문제를 해결할 때 1C:Enterprise 플랫폼에서 제공되지 않는 상호 작용 프로토콜, 데이터 형식과 같은 특정 요구 사항을 처리해야 합니다. 이러한 다양한 작업을 위해 플랫폼은 다음을 제공합니다. 외부 부품 기술, 1C:Enterprise의 기능을 확장하는 동적으로 플러그인 모듈을 생성할 수 있습니다.

유사한 요구 사항이 있는 작업의 일반적인 예는 저울에서 금전 등록기 및 바코드 스캐너에 이르는 소매 장비와 1C 애플리케이션 솔루션을 통합하는 것입니다. 외부 구성 요소는 1C:Enterprise 서버 측과 클라이언트 측 모두에 연결할 수 있습니다(웹 클라이언트 및 클라이언트 측을 포함하되 이에 국한되지 않음). 모바일 플랫폼의 다음 버전 1C:기업). 외부 구성 요소 기술은 개발자가 구현해야 하는 1C:Enterprise 플랫폼과 구성 요소의 상호 작용을 위해 매우 간단하고 이해하기 쉬운 소프트웨어(C++) 인터페이스를 제공합니다.

외부 구성 요소를 사용할 때 열리는 가능성은 매우 넓습니다. 외부 장치 및 시스템과의 특정 데이터 교환 프로토콜을 사용하여 상호 작용을 구현하고, 데이터 및 데이터 형식 처리를 위한 특정 알고리즘을 구축할 수 있습니다.

오래된 통합 메커니즘

플랫폼은 새로운 솔루션에 사용하지 않는 것이 권장되는 통합 메커니즘을 제공합니다. 이는 이전 버전과의 호환성을 이유로 남겨두며, 상대방이 최신 프로토콜을 사용하여 작업할 수 없는 경우에도 마찬가지입니다. 그 중 하나는 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
• "CORP 기업 회계", 에디션 3.0
• "소매", 에디션 2.0
• "기본 무역 관리", 11판
• 무역 관리, 제11판
• "급여 및 인사 관리 CORP", 에디션 3

데이터 교환에 사용되는 형식은 다음과 같습니다. 엔터프라이즈데이터, XML을 기반으로 합니다. 형식은 비즈니스 지향적입니다. 여기에 설명된 데이터 구조는 1C 프로그램에 표시되는 비즈니스 엔터티(문서 및 디렉터리 요소)에 해당합니다(예: 완료 행위, 현금 영수증 주문, 상대방, 항목 등).

1C 애플리케이션과 타사 애플리케이션 간의 데이터 교환이 발생할 수 있습니다.

• 전용 파일 디렉토리를 통해
• FTP 디렉토리를 통해
• 1C 애플리케이션 측에 배포된 웹 서비스를 통해. 데이터 파일은 웹 메소드에 매개변수로 전달됩니다.
• 이메일을 통해

웹 서비스를 통한 교환의 경우 타사 애플리케이션은 1C 애플리케이션의 해당 웹 메서드를 호출하여 데이터 교환 세션을 시작합니다. 다른 경우에는 교환 세션의 시작자가 1C 애플리케이션이 됩니다(데이터 파일을 적절한 디렉터리에 배치하거나 데이터 파일을 구성된 이메일 주소로 전송).
또한 1C 측에서는 동기화 발생 빈도를 구성할 수 있습니다(디렉토리 및 이메일을 통한 파일 교환 옵션의 경우).

• 일정에 따라(지정된 빈도로)
• 수동으로; 사용자는 필요할 때마다 수동으로 동기화를 시작해야 합니다.

메시지 확인

1C 애플리케이션은 보내고 받은 동기화 메시지의 기록을 유지하며 타사 애플리케이션에서도 동일한 메시지를 기대합니다. 이를 통해 위의 "데이터 교환 메커니즘" 섹션에 설명된 메시지 번호 매기기 메커니즘을 사용할 수 있습니다.

동기화 중에 1C 애플리케이션은 마지막 동기화 이후 비즈니스 엔터티에 발생한 변경 사항에 대한 정보만 전송합니다(전송되는 정보의 양을 최소화하기 위해). 첫 번째 동기화 중에 1C 응용 프로그램은 EnterpriseData 형식의 모든 비즈니스 엔터티(예: 항목 참조 도서 항목)를 XML 파일로 업로드합니다(모두 외부 응용 프로그램의 경우 "새" 항목이므로). 타사 응용 프로그램은 1C에서 받은 XML 파일의 정보를 처리하고 다음 동기화 세션 중에 1C로 보낸 파일의 특수 XML 섹션에 특정 번호가 있는 1C의 메시지가 성공적으로 전달되었다는 정보를 배치해야 합니다. 받았다. 영수증 메시지는 모든 비즈니스 엔터티가 외부 애플리케이션에 의해 성공적으로 처리되었으며 더 이상 이에 대한 정보를 전송할 필요가 없다는 신호를 1C 애플리케이션에 보냅니다. 영수증 외에도 타사 응용 프로그램의 XML 파일에는 응용 프로그램의 동기화를 위한 데이터(예: 상품 및 서비스 판매 문서)도 포함될 수 있습니다.

수신 메시지를 받은 후 1C 애플리케이션은 이전 메시지에서 전송된 모든 변경 사항을 성공적으로 동기화된 것으로 표시합니다. 비즈니스 엔터티에 대한 동기화되지 않은 변경 사항(새 엔터티 만들기, 기존 엔터티 변경 및 삭제)만 다음 동기화 세션 동안 외부 응용 프로그램으로 전송됩니다.

외부 애플리케이션에서 1C 애플리케이션으로 데이터를 전송할 때 그림이 반전됩니다. 외부 애플리케이션은 그에 따라 XML 파일의 영수증 섹션을 작성하고 동기화할 비즈니스 데이터를 EnterpriseData 형식으로 배치해야 합니다.

핸드쉐이크 없이 단순화된 데이터 교환

간단한 통합의 경우 타사 응용 프로그램에서 1C 응용 프로그램으로 정보를 전송하는 것만으로도 충분하고 1C 응용 프로그램에서 타사 응용 프로그램으로 데이터를 역방향으로 전송할 필요가 없는 경우(예: 온라인 통합) 판매 정보를 1C로 전송하는 스토어: 회계), 1C 애플리케이션 측면에서 설정이 필요하지 않은 웹 서비스(승인 없이)를 통해 작업하는 단순화된 옵션이 있습니다.

맞춤형 통합 솔루션

표준 1C 구성 간에 데이터를 변환하고 교환하기 위해 플랫폼 메커니즘을 사용하지만 타사 응용 프로그램과의 통합에도 사용할 수 있는 표준 솔루션 "1C: 데이터 변환"이 있습니다.

뱅킹 솔루션과 통합

표준 "고객 은행"1여년 전에 10C 전문가가 개발한 는 실제로 러시아의 산업 표준이 되었습니다. 이 방향의 다음 단계는 기술입니다. 다이렉트뱅크, 1C 프로그램에서 버튼 하나를 눌러 결제 문서를 은행에 보내고 1C:Enterprise 시스템 프로그램에서 직접 은행으로부터 명세서를 받을 수 있습니다. 클라이언트 컴퓨터에 추가 프로그램을 설치하고 실행할 필요가 없습니다.

또한있다 급여 프로젝트의 데이터 교환 표준.

기타

언급할 가치가 있는 1C:Enterprise 시스템과 웹사이트 간의 프로토콜 교환, 상업 정보 교환 표준 커머스ML (Microsoft, Intel, Price.ru 및 기타 회사와 공동 개발) 거래 획득을 위한 데이터 교환 표준.

출처 : habr.com