sap slt что это
SAP BW на HANA — репликация SLT HANA
Репликация SAP Landscape Transformation (SLT) — это метод репликации данных на основе триггера в системе HANA. Это идеальное решение для репликации данных в реальном времени или репликации на основе расписания из источников SAP и сторонних производителей. Он имеет сервер репликации SAP LT, который отвечает за все триггерные запросы. Сервер репликации может быть установлен как автономный сервер или может работать в любой системе SAP с SAP NW 7.02 или выше.
Существует надежное RFC-соединение между БД HANA и системой транзакций ECC, которое обеспечивает репликацию данных на основе триггера в системной среде HANA. На следующем рисунке показан сценарий репликации SAP HANA SLT для репликации данных в режиме реального времени.
Преимущество репликации SLT
Ниже приведены преимущества репликации SLT.
Метод SLT Replication позволяет реплицировать данные из нескольких исходных систем в одну систему HANA, а также из одной исходной системы в несколько систем HANA.
SAP LT использует триггерный подход. Он не оказывает заметного влияния на производительность исходной системы.
Он также обеспечивает преобразование данных и возможность фильтрации перед загрузкой в базу данных HANA.
Он позволяет реплицировать данные в режиме реального времени, реплицируя только соответствующие данные в HANA из исходных систем SAP и сторонних производителей.
Он полностью интегрирован с системой HANA и студией HANA.
Метод SLT Replication позволяет реплицировать данные из нескольких исходных систем в одну систему HANA, а также из одной исходной системы в несколько систем HANA.
SAP LT использует триггерный подход. Он не оказывает заметного влияния на производительность исходной системы.
Он также обеспечивает преобразование данных и возможность фильтрации перед загрузкой в базу данных HANA.
Он позволяет реплицировать данные в режиме реального времени, реплицируя только соответствующие данные в HANA из исходных систем SAP и сторонних производителей.
Он полностью интегрирован с системой HANA и студией HANA.
Создайте надежное RFC-соединение в системе ECC
В вашей исходной SAP-системе AA1 вы хотите установить доверенный RFC к целевой системе BB1. Когда это будет сделано, это будет означать, что когда вы вошли на AA1 и ваш пользователь имеет достаточные полномочия на BB1. Вы можете использовать RFC-соединение и войти на BB1 без повторного ввода имени пользователя и пароля.
Используя доверительные / доверительные отношения RFC между двумя системами SAP: от доверенной системы RFC до доверяющей системы, пароль для входа в доверяющую систему не требуется.
RFC-адрес ECCHANA (введите имя RFC-адресата) Тип подключения: 3 (для системы ABAP)
Перейдите к технической настройке: введите целевой хост: имя системы ECC, IP и введите номер системы.
Central Finance Tips and Tricks #5 – SLT
The SLT system is a critical component of central finance and is responsible to transfer real time replication data from source systems to the central system for both SAP and non-SAP systems. It also has the role of completing the initial load for cost object and controlling interfaces.
Where do you get started?
Great information and pre-defined templates are delivered by SAP to help accelerate and get you off to a solid start, refer to SAP notes:
Note 2154420 has the prerequisite SLT components needed for each release. The DMIS add on is required on source systems and SLT itself, for the S/4 system the S4CORE component must be installed. To avoid issues the highest available version of DMIS is recommended to be installed.
Setup
The basic setup involves the use of transaction LTRC, this provides a wizard to create the connection between source and target systems. Before performing the initial setup some key points need to be considered.
In the SLT server, start transaction LTRC, choose the new pushbutton to create a new configuration. In the step Specify General Data, enter a configuration name (without any spaces). In addition, you can specify a description.
In the step Specify Source System, you specify the connection data to the source system. In this case, specify an existing RFC connection to the source system.
In the step Specify Target System, the connection data to the target system must be defined. Select the RFC Connection radio button, and enter the existing RFC connection to the target system. In the field Scenario for RFC Communication, choose RFC scenario
In the step Specify Transfer Settings, you can define the initial load mode. I recommend using the option Performance Optimized but you will need approximately 10 % additional storage in the source system during the initial load. In the No. of Data Transfer Jobs field, enter the appropriate value e.g. 6. Note that you can increase this value later if required. Set data class of table space e.g. APPL1. Set the replication frequency as Real time.
In the step Review and Create, you can review your settings. Ensure that all settings are correct and choose the push button Create Configuration.
The mass transfer ID (MTID) is an internal number. You need this information to activate the pre-delivered objects in MWB. The MTID is also visible in transaction LTRC. Communication between source > SLT > Central Finance is now established.
Mapping
When SLT is performing the initial load and replicating data, for both phases a migration workbench (MWB) object is created for every trigger table. A MWB objects stores the information of the source structure, the target structure and how the mapping should be executed. In other words, the MWB object holds the rules that transform the data from the table based structures on the source system into the remote function module interface of the central finance system. This is different from a table based standard scenario, like HANA replication, where the table is moved as an exact copy from source to the target.
For S/4 HANA 1511 to 1610 releases Central Finance is working with three trigger tables AUFK, CFIN_ACCHD, and COBK. From 1709 onwards SAP have added other tables to support tax, withholding tax, commitments, accounting view of logistics data and EC-PCA postings.
An initial load object and a replication object must be created for each table. All of the MWB objects are stored for each configuration in LTRC and can be adjusted accordingly. SAP have done a great job and done most of the work, where templates can be download and installed using the notes mentioned in the getting started section above.
Before you start the replication, you must create the initial load and replication objects. To define the initial load and replication objects start program DMC_UPLOAD_OBJECT in transaction SE38 and upload the relevant files from SAP note 2154420. It is possible for customer specific adjustments can be made to the mapping rules.
Once the template rules are available, they are applied to each mass transfer ID on the SLT server. This is completed after the setup of the mass transfer ID is completed for each source system.
Before you start the replication in each SLT system, you must create the initial load and replication objects. To define the initial load and replication objects use LTRC for the mass transfer ID, tab processing steps and the step Create Predefined Load and Replication Objects
Choose the Copy Predefined Object pushbutton, and enter the REPL_CFIN template in the Project field. Depending on whether you are integrating SAP or Non SAP system choose the relevant Subproject, in this case I am selecting REPL_CFIN. In the Predefined Object field, you specify the predefined initial load object. Use the F4 help to view all available objects. For every table, there is a load object and a replication object. The load object contains the suffix L and replication object _R.
Under Target Object, you have to specify the table name. Use the same table that you specified for the predefined replication object. For example, if your predefined replication object is CFI_COBK_L, your table name is COBK. Repeat for the replication object with the predefined object with suffix _R and select the replication radio button.
Repeat the process for the other tables that require replication e.g. CFIN_ACCHD and AUFK.
Navigate back to the overview of the predefined objects and set the status of the initial load and replication objects to Active.
Once the replication objects are defined it is critical to perform a DDIC synch. This ensures that the MWB objects are consistent between source and target systems so runtime objects are created correctly.
From LTRC for the mass transfer ID, tab processing steps and the step Create Predefined Load and Replication drill down into the “ _TEMPLATE” MWB subproject.
When you start the replication from LTRC, SLT should automatically synchronize the data dictionary (DDIC) structures between the source and target systems. In some exceptional cases this does not occur and can lead to multiple short dumps due to DDIC inconsistencies. In this case it is possible to OPTIONALLY force the generation of runtime objects using the steps below:
Filters
Filters ensure that only the relevant data is transferred to Central Finance. Two types of filters can be defined:
For the controlling interface, I recommend that a trigger filter is applied to table COBK and aligns with the initial load starting date set in view VCFIN_SOURCE_SET on source systems. For large installations that have lots of history, this will speed up the initial load process and only select relevant data. In some cases, it may be necessary to implement a runtime filter, for example where different initial load start dates are required for different company codes, or you need to filter out company codes on the Controlling interface.
Example Trigger Filter
You define trigger filters in transaction LTRS with respect to a configuration and table in the performance options folder. The reading type must be set to 4 or 5 for trigger filters to be defined. The example below shows a filter on table COBK with posting date >= 01 August 2018.
You can also disable update and delete triggers if desired using the Tables folder in LTRS.
Example Run time Filter
Run time filters are defined in the MWB content. Using transaction MWB navigate to the TEMPLATE subproject for the mass transfer ID where rules are to be defined and select the conversion logic icon. Here the template rules will be shown and can be adapted.
The example below shows a run time filter on COBK for event related rule SKIP_COBK to filter the record out of the posting date is less than 01 August 2018.
Execution
The Central Finance initial load process consists of two different parts.
For the Accounting interface, it transfers via RFC the FI documents, the balances and open items to the central system in CFIN* staging tables on the central finance system (not via SLT!)
For the Controlling interface, the CFINIMG activity Prepare for and Monitor the Initial Load of CO Postings must be executed before the table COBK initial load is started from the SLT system. This prerequisite step stores the CO-PA characteristics in a source system database table CFIN_COPA for the initial load of the CO documents.
The initial load and replication for the tables AUFK, CFIN_ACCHD, COBK is executed via transaction LTRC on the SLT systems. In the context of Central Finance, the SLT initial load of CFIN_ACCHD refers to the loading of documents posted on source system since the start of the RFC initial load performed from the Central Finance system.
When the MWB objects are activated you can use SAP LT Replication Server to control your load and replication. In the SAP LT Replication Server Cockpit (transaction LTRC) enter your mass transfer ID. In the Table Overview tab page, you can stop or start a table by choosing the Data Provisioning pushbutton.
The option Start Load will execute an initial load of the data that is currently in the system. But there will be no delta replication. Using this function is generally not required. It could come in use for recovery scenarios where you need to load some data and not activate real time replication.
The option Start Replication will execute an initial load of the data and activates delta recording. After the initial load, the replication of delta data will start, no manual interaction is required
Enter the table (e.g. AUFK, CFIN_ACCHD, COBK) for which you have defined your predefined objects and choose Start Replication.
Monitoring
You can monitor the load and the replication using transaction LTRC. On the tab page Data Transfer Monitor, you can view the table name once the initial load or replication object is created and view the status of the replication and objects. The tab Load Statistics is useful during the initial load phase to give you an overview of progress. The Application Log can be used to help troubleshoot and analyse issues, the log contains details about any issues regarding the replication process, and information if data cannot be replicated to the target system because of incorrect settings.
In many cases it is hard in SLT to detect the exact problem and you will need to use LTRC, ST22 and SM21 to trouble shoot.
To monitor more than one configuration at a time transaction LTRO can be used.
Alerts
Setting up automatic alerts to send out notifications in case of issues in SLT is recommended. This helps avoid permanent monitoring of SLT. Notifications can be activated for a dedicated configuration. If activated, the system uses a background job to check the configuration periodically:
The frequency and thresholds can be set up on a table basis per configuration. This is done in LTRC in the Expert Functions tab.
Reset Transfer Status / Repeated Testing
Central finance uses function modules to transfer data. Using this technique SLT stores the key references during initial load and replication into table DMC_FM_RESTART to ensure that the same data cannot be replicated to the target system again.
For testing it is likely that reloading of SLT data to Central Finance is required, due to configuration changes, defects etc. To reuse an existing mass transfer ID and load the same documents again you must first remove the entries in table DMC_FM_RESTART, otherwise none or not all data will be transferred to Central Finance.
To remove the entries, use transaction SE38 and enter the report DMC_FM_RESTART_COPY_DELETE enter the table name e.g. CFIN_ACCHD and choose Reset Transfer Status.
Managing Outages
As part of operations it is necessary to suspend the SLT replication from time to time to accommodate events such as upgrades and patching. When deactivating replication, the source systems will accumulate entries in the logging tables and these will be cleared down and processed to the central finance system once the SLT configuration is reactivated. However, for the AC_DOC Accounting interface for SAP source systems, sequencing is enabled with interface version 2 and there is no guarantee that SLT will processes the postings in the correct sequence. Read SAP note 2679070 – Central Finance: Resuming SLT replication that provide the steps to avoid sequencing issues:
Structural Changes
From time to time data models may change on source or target central finance systems as a result of upgrades, configuration changes such as adding a new field to COPA or extending a field in the general ledger, also known as a coding block extension.
In all cases the SLT configuration must be deactivated before the structural changes are imported into the source or target system. When the replication is restarted SLT will normally automatically detect the changes and regenerate the run time objects. In some cases this could go wrong, for example the sequence was not strictly followed. In this case the run time objects will need to be synchronized and regenerated (Refer note 2531470).
Good to Know
My most frequently used SLT transactions
Интеграция Central Finance с не-SAP системами-источниками на примере 1С
Дорогобид Антон
Архитектор, эксперт SAP
Функциональность SAP S/4 HANA Central Finance (далее CFIN) превратилась из системы финансовой отчетности в платформу трансформации, позволяющую централизованно выполнять различные финансовые сценарии. При этом, все чаще встает вопрос о том, каким образом подключить не-SAP системы-источники, такие как Oracle, Axapta, JD и т.д.. Для российского рынка и стран СНГ, наиболее актуален вопрос подключения к CFIN разных версий приложений «1С».
Почему этот вопрос так важен?
Предпосылки
Почему этот вопрос так важен?
В первую очередь потому, что подключение различных систем к интерфейсу CFIN позволяет в полной мере использовать возможности системы S/4 HANA для достижения различных целей:
Цель данной статьи заключается в представлении экспертного мнения в профессиональном сообществе о доступных альтернативах при реализации интеграции «1С» приложений и CFIN, основанном на существующем в РФ и странах СНГ опыте и лучших мировых практиках. Указанный сценарий интеграции является наиболее востребованным на территории РФ.
Статья опирается на S/4 HANA 1909, но также применима к более ранним версиям, если не указано иное. Для знакомства с Central Finance, рекомендуется изучение курсов S4F60 и S4F61.
Варианты решений
На сегодняшний день существует всего два подхода к реализации:
Как правило, второй подход чаще всего обусловлен двумя причинами:
Для таких случаев, во второй части статьи описан рекомендованный вариант реализации коннектора собственными силами с указанием наиболее важных аспектов, которые необходимо учитывать при проектировании и реализации собственной разработки.
Способы интеграции с не-SAP системами
Как же обеспечить взаимодействие системы CFIN и систем-источников «1С»?
Традиционно интерфейс взаимодействия с не-SAP системами представлен на рис.1
Рис.1 Классическая архитектура Central Finance
Основная задача состоит в реализации коннектора, который должен обеспечивать выгрузку данных из не-SAP системы, выполнять мэппинг и заполнять Staging-tables (промежуточные таблицы).
Учитывая, что в настоящий момент существует два подхода, рассмотрим каждый из них с точки зрения следующей структуры:
Механизм интеграции от компании Магнитьюд [1]
Компания Магнитьюд уже много лет занимается реализацией механизмов интеграции для обеспечения взаимодействия не-SAP систем и системы CFIN. В 2020 году, начались работы по разработке механизма интеграции между приложениями «1С» и CFIN. На момент написания данной статьи, решение от компании Магнитьюд является расширением (addon) к CFIN и лицензируется отдельно, как SAP-продукт.
В решение входят следующие функциональные блоки:
Архитектура решения представлена на рисунке 2 ниже:
Рис.2 Архитектура решения от Магнитьюд
Далее, рассмотрим решение от Магнитьюд более детально:
1. Обеспечение передачи основных данных из приложений «1С»
Для обеспечения передачи основных данных реализован модуль Гармонизации данных, который в автоматическом режиме обрабатывает создание, изменение и удаление основных данных в системах-источниках и CFIN.
Рис.3 Компоненты модуля гармонизации данных
Модуль Гармонизации данных включает в себя четыре ключевые возможности, которые помогают ускорить и автоматизировать многие ручные задачи, связанные с переносом основных данных из систем-источников в CFIN и MDG (Master Data Government):
Если данные не удалось сопоставить друг с другом, то эти ошибки отражаются в интерфейсе AIF в CFIN.
Для устранения ошибок сопоставления существует интерфейс ручной обработки не сопоставленных основных данных, который требует участия конечного пользователя. Он необходим для обработки мэппинга данных, который система не может определить автоматически.
Для обеспечения корректной работы основных мэппингов, необходимо на этапе настройки системы, выполнить мэппинг полей основных данных (группа счетов, контрольный счет, налоговая информация и т. д.). Данный мэппинг выполняется вручную, через отдельный интерфейс, так как статические элементы конфигурации (редко меняющиеся параметры настройки) необходимо настраивать в CFIN. Модуль от Магнитьюд может извлекать такие элементы данных из исходных 1C и предоставлять заказчику / системному интегратору для создания в CFIN.
Если у клиента есть собственная MDG-система, то данные из нее возможно загрузить в интерфейс Magnitude SourceConnect через плоский файл / xml. При этом, есть возможность настроить приоритет для данных определенной системы (в случае если основные данные поступают из нескольких систем).
Процесс гармонизации данных тесно связан с процессом передачи транзакционных данных.
Рис.4 Процесс гармонизации данных
Возможности модуля Гармонизации данных объясняют почему те компании, которые уже используют Магнитьюд, при необходимости подключения новых систем, в том числе SAP-систем, предпочитают делать это используя функциональность от Магнитьюд.
2. Обеспечение выгрузки транзакционных данных из приложений «1С»
Важно отметить, что для репликации транзакционных данных используется стандартный интерфейс, то есть модуль от Магнитьюд заполняет таблицы SAP Staging, а потом уже работает стандарт SLT.
Рис.5 Поток транзакционных данных из 1С
Ключевые особенности блока репликации транзакционных данных от Магнитьюд:
Обратные проводки в приложение «1С» реализуются также при помощи специальных API, которые позволяют, например, создать документ платежа в приложении «1С».
4. Обеспечение мэппинга технических данных и аналитических признаков для перекладки транзакционных данных в специальные staging-таблицы
Мэппинг технических данных встраивается в процесс извлечения данных из системы-источника. Он выполняется с использованием комбинирования ракурсов экстракции данных и специально разработанного функционала бизнес-правил.
Технические атрибуты не могут быть сопоставлены при помощи стандартного MDG. Специально разработанная структура мэппинга используется для определения связанных данных между приложениями «1С» и SAP.
5. Обеспечение сверки как основных данных, так и транзакционных данных и обработка ошибок
Отчеты по согласованию позволяют сравнивать изменения данных транзакции на этапах репликации и преобразования из исходной системы в SAP S/4 HANA. Отчеты помогают определить этап, содержащий неверные или отсутствующие данные, которые необходимо проверить.
Рис.6 Уровни сверки данных
Процедура сверки у Магнитьюд выполнена на пяти уровнях данных:
Кроме этих отчетов предусмотрены еще два дополнительных отчета:
Стоит отметить, что в части сверки данных, Магнитьюд расширяет возможности стандартной функциональности CFIN. В стандарте имеется один уровень сверки данных, поэтому сверка выполняется лишь между системой-источником и центральной системой. При этом, при выявлении ошибки, бывает сложно понять на каком именно этапе она возникла и чем вызвана. Например, в AIF не попадает ошибка интеграции/мэппинга на стороне SLT, либо система выдает ошибку, которая требует детального анализа. В функциональности Магнитьюд, благодаря многоуровневой сверке, имеется возможность легко понять в какой момент и из-за чего произошла ошибка и внести необходимые корректировки.
Все проверочные отчеты реализованы на FIORI и на базе Analyzes for Office. FIORI-отчеты скомпонованы в единый Dashboard (см. на скриншоте ниже)
Рис.7 Пример панели отчетов Fiori от Magnitude
В дополнение, более детально рассмотрим процесс обработки ошибок, начиная от обнаружения ошибки до ее корректировки
Функциональные ошибки обычно передаются в AIF, где происходит обычное устранение неполадок, исправление и повторная обработка.
Технические ошибки (например, сбой сети, сервера или базы данных) обрабатываются следующим образом:
6. Обеспечение drilldown из центральной системы к данным приложения «1С»
Рис.8 Переход к данным первичного документа из не-SAP системы
Приложение от Магнитьюд предназначенное для перехода в первичный документ реализовано, как расширение Manage Journal Entries Fiori app, и показывает данные соответствующие типу документа в универсальном журнале. Если документ является инвойсом клиенту, приложение отображает соответствующие данные из системы-источника (основные счета, контрагент, данные отгрузки и т.д.). Если документ является входящим инвойсом, приложение отображает соответствующие данные из системы-источника (основные счета, поставщик, данные поставки и т.д.). Для прочих типов документов выводится информация релевантная данным проводки по основным счетам.
Механизм Drilldown может быть расширен дополнительными полями. Важно понимать, что функционал от Магнитьюд не создает логистические проводки, но собирает все необходимые данные либо в поля универсального журнала, либо в специальный репозиторий Drilldown на стороне SAP Data Service (по сути отдельная таблица в базе данных HANA).
Реализация коннектора собственными силами
Рассмотрим реализацию коннектора собственными силами также в разрезе указанной структуры:
В силу того, что первые три задачи имеют общий механизм реализации, рассмотрим их в совокупности.
1. Передача основных и транзакционных данных, а также реализация обратной проводки.
Указанные задачи чаще всего вызывают больше всего вопросов, поэтому было принято решение уделить им достаточно много внимания. Но чтобы не перегружать статью излишними техническими деталями, часть информации вынесена в Приложение.
Для обеспечения интеграции программных продуктов компании «1С», как между собой так и между сторонними приложениями, был разработан специальный формат обмена данными EnterpriseData. Данный формат является бизнес-ориентированным и базируется на XML. Описанные в нем структуры данных соответствуют документам и элементам справочников, представленным в программах «1С», например: акт выполненных работ, приходный кассовый ордер, контрагент, договор и т. п. С одной стороны это облегчает понимание операций, с другой стороны несколько затрудняет мэппинг на структуры SAP, так как наименования документов и справочников приведены на кириллице.
Детальное описание формата EnterpriseData (ED) и его использование для обмена данными приведено в приложении к статье.
Формат разрабатывался, в первую очередь, для синхронизации данных между программными продуктами самой фирмы «1С». На момент подготовки статьи, этот формат поддерживал следующие продукты:
Далее рассмотрим как выглядит обмен данными при помощи ED.
На рисунке 9 представлен возможный вариант обмена данными при помощи формата ED
Рис.9 Вариант обмена данными
Для обеспечения обмена данными в формате ED между приложением «1С» и сторонним приложением SAP, необходимо на стороне «1С» выполнить настройку для синхронизации данных. В настройке необходимо указать уникальный код приложения, с которым будет производиться обмен, а также определить по какому каналу будет происходить обмен данными. В настоящий момент доступны следующие опции:
Рассмотрим эти опции чуть детальнее.
В случае обмена через веб-сервис стороннее приложение будет инициировать сеанс обмена данными путем вызова соответствующих веб-методов приложения «1С». В остальных случаях инициатором сеанса обмена будет приложение «1С». Если нет технических ограничений, то рекомендуется использовать опцию обмена через веб-сервис.
Для двухстороннего обмена между конфигурацией «1С» и сторонними приложениями, на стороне «1С» должен быть развернут веб-сервис EnterpriseDataExchange. Двухсторонний обмен требуется для реализации обратной проводки.
При использовании веб-сервиса инициатором сеанса обмена выступает стороннее приложение. В нашем случае SAP-приложение (Data Service). Упрощенно процесс выглядит так:
На самом деле процесс несколько сложнее и есть определённые нюансы, которые, чтобы не загружать читателя излишней информацией, также вынесены в раздел Приложение Веб-сервис.
В случае обмена данными (файловый обмен) через каталог/FTP каталог или электронную почту инициатором обмена будет выступать приложение «1С».
Оно будет помещать в соответствующий канал (каталог или почтовый ящик) файл описанного специального формата и ожидать от стороннего приложения в этом же канале ответных файлов.
В случае обмена по электронной почте тема письма должна быть составлена по определенному правилу, а заархивированный файл с данными должен быть приложен к письму.
Также для вариантов с файловым обменом через каталог и электронную почту, на стороне «1С» настраивается, с какой периодичностью будет происходить синхронизация:
Выбор того, как часто будет выполняться обмен, зависит от преследуемых целей. Если нужна отчетность в режиме реального времени, то синхронизация данных должна осуществляться гораздо чаще чем пару раз в день. Если же речь идет об оптимизации закрытия периода, например, для исключения необходимости сверки внутригрупповых расчетов, то для этих целей достаточно будет синхронизировать данные на ежедневной основе.
Поэтому, от варианта реализации выгрузки основных и транзакционных данных будут зависеть и все остальные возможности коннектора: передача изменений документа, возможность доступа к первичным данным и сверка данных.
2. Мэппинг технических данных и аналитических признаков
Этот этап с точки зрения трудоемкости и важности – ключевой. Подавляющее количество ошибок, как правило связано именно с мэппингом данных. Речь идет, в первую очередь, о мэппинге данных из XML-файла в формате ED в формат Staging tables на стороне SLT.
Staging Tables – это промежуточные таблицы, необходимые для организации интерфейса сторонней системы. Они представляют собой запись журнала, которая должна быть проведена в системе CFIN.
Мэппинг реализуется на стороне SAP-системы при помощи разработки. На основе XSD-схемы выстраиваются маршруты обработки данных в зависимости от типов передаваемых данных.
В случае с приложениями «1С» мы имеем дело с двум типами данных:
Соответственно, при передаче объекта с типом «Справочник», потребуется выполнить следующие шаги:
При передаче объекта с типом «Документ», алгоритм несколько иной:
Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland