Разработка модуля интеграции SAP
Оглавление
Введение
. Интегрируемые системы и подходы к их интеграции
.1 Интеграция информационных систем
.2 Методы передачи данных между ИС
.2.1 Обмен плоскими файлами
.2.2 Общая БД
.2.3 Прямая связь систем
.2.4 Централизованный брокер сообщений
.2.5 Интеграционная шина
.3 Анализ интегрируемых ИС
.3.1 Информационная среда ПНППК
.3.2 Система SAP R/3
.3.3 Система «База производства ВОГ»
.4 Сравнение методов интеграции ИС
.5 Анализ аналогичных решений
.5.1 SAP PI
.5.2 Использование SAP .NET Connector
.5.3 Сравнение аналогов
. Интеграционное решение в бизнес-процессах ПНППК
.1 Анализ бизнес-процесса планирования и управления
производством
.2 Анализ процесса исследования неисправных изделий
.3 Место анализа КУН в процессе планирования и управления
производством
. Разработка интеграционного решения
.1 Проектирование интеграционного решения
.1.1 Структура данных в МУННС
.1.2 Структура передаваемых данных
.1.3 Проектирование функционала модуля
.1.4 Архитектура интеграционного решения
.2 Реализация интеграционного решения
.2.1 API в «Базе производства ВОГ»
.2.2 BAPI в SAP R/3
.2.3 Разработка интеграционного модуля
Заключение
Основные обозначения и сокращения
Библиографический список
Приложения
Введение
информационный файл база connector
Крупномасштабное производство является значимой частью экономик всех
стран мира еще с давних пор и контроль за ним всегда был первостепенной задачей
предпринимателей и компаний. Сегодня уже существует множество ИТ-решений,
которые призваны помочь им наиболее эффективно управлять своим делом.
В любом производстве есть вероятность брака, неисправности, и их учет
крайне важен для предприятия при планировании производства, так как чем четче
происходит анализ производства, чем прозрачнее оно становится, тем эффективнее
можно им управлять, а более высокая эффективность ведет к большей прибыли. Но
мало просто отслеживать и учитывать бракованные изделия, это нужно делать
максимально оперативно.
Для ПНППК решение данного вопроса достаточно актуально, так как в ее
ERP-системе SAP R/3, которая охватывает большинство бизнес-процессов компании,
отсутствует возможность учета неисправных изделий, а разработка полноценного
модуля потребует достаточно много трудовых ресурсов. Также компания имеет
стороннюю разработку - web-систему “База производства ВОГ”, которая имеет
возможность вести учет карточек учета неисправностей (КУН).
Проблема заключается в отсутствие возможности учитывать неисправные
изделия в системе SAP R/3 для планирования производства при имеющейся системе
«База производства ВОГ» c возможностью их отслеживания.
Объектом исследования является система отслеживания и учета неисправных
изделий, а предметом - способы интеграции систем “База производства ВОГ” и SAP
R/3.
Целью работы является автоматизация учета неисправных изделий в системе
SAP R/3 на основе карточек учета неисправностей в системе “База производства
ВОГ” для планирования производства предприятия.
Задачи:
) проанализировать проблему интеграции корпоративных систем;
) исследовать возможные методы интеграции систем и выбрать один из
них;
) определить места применения информации о неисправных изделиях в
процессах планирования и управления производством;
) спроектировать и разработать интеграционное решение.
Для выбора подхода к интеграции систем будет использован такой метод
исследования, как сравнительный анализ: будут изучены сильные и слабые стороны
каждого из подходов. Для рассмотрения интеграции на уровне бизнес-процессов
будет использован анализ таких документов, как пособие по планированию и
управлению производством в SAP R/3 [5] и стандарт предприятия о “Технологии
исследования изделий, отказавших у потребителя и в процессе производства” [2].
На основании результатов анализа будет проведено моделирования процессов
планирования производства и исследования неисправных изделий в нотации ARIS. Для определения набора передаваемых
в SAP R/3 данных будут проведены интервью с непосредственными
пользователями.
В первой главе работы будет изучена проблема интеграции корпоративных
систем, подходы ее решению и выбран один из них. Во второй главе будут
проанализированы процессы планирования производством и исследования неисправных
изделий, изучено место их интеграции. В третьей главе будет описан процесс
реализации интеграционного решения, включающий в себя его проектирование и
разработку.
1. Интегрируемые системы и подходы к их интеграции
В данной главе будет проанализированы проблема интеграции информационных
систем и сами исследуемые системы. Далее будут изучены подходы к интеграции и,
учитывая технические возможности систем, выбран один из них.
1.1 Интеграция информационных систем
Проблема интеграции корпоративных ИС не нова, ведь зачастую процесс
внедрения различных систем управления происходит постепенно. Сначала систему
внедряют в отдельные подразделения, начиная с бухгалтерии или отдела кадров. В
конечном счете в компании образуется информационная среда, которая состоит из
разнородных систем, разработанных в разное время, разными людьми, на разных
платформах и т.д. Такую автоматизацию управления обычно называют «лоскутной»,
причины чего заключаются в следующем:
− функциональность отдельных ИС
является более выигрышной из-за заданной прикладной области;
− стоимость внедрения отдельных систем
намного дешевле;
− отсутствие карты решений службы ИТ.
Если не предпринимать шаги к интеграции этих систем, то они начинают
работать изолированно и хранить в себе отдельные и несопоставимые данные.
Системы управления предприятием, призванные решить данную проблему, часто
также требуют интеграции с какой-либо другой системой. А.А. Кусов в своей работе
[10] проанализировал, почему с современными системами управления, например,
ERP, все равно присутствует необходимость иметь на предприятии несколько ИС и
интегрировать их. По его мнению, данная проблема исходит и от самих поставщиков
корпоративных программных продуктов: “Они утверждают, что продукты класса ERP
(ERP II, CSRP и BPM) «автоматически» снимают проблему интеграции”.
Действительно, считается, что системы данного класса призваны автоматизировать
практически все бизнес-процессы и что приложения системы уже интегрированы
между собой, так как они от одного поставщика.
Правда в том, что ни одна система не может решить все задачи предприятия,
поэтому требуется покупка дополнительного модуля или разработка собственного
для реализации нужных функций и, следовательно, проведение интеграции.
В зависимости от того, какие методы связи использованы, выделяют уровни
интеграции, перечисленные ниже.
1. Уровень брокеров - автоматическая передача данных и запуск
исполняемого кода на выполнение. Для конечного пользователя интегрированные
компоненты представляют единую систему.
. Уровень данных - использование единой или нескольких
объединенных БД. Для конечного пользователя данные будут выглядеть целостными.
. Уровень сервисов - зачастую подразумевает под собой архитектуру
SOA, где все функции систем рассматриваются как обособленные сервисы, которые
могут использоваться множество раз.
. Уровень интерпретирования метаинформации - ИС хранит данные в
самоописывающем хранилище, а пользователь может модифицировать не только их, но
и метаданные, переналаживая ИС под постоянно меняющиеся требования решаемой
задачи.
Также выделяют три степени интеграции систем в зависимости от количества
операций, выполняемых человеком: ручная, автоматизированная и автоматическая.
Зависимость степени интеграции от использованного метода можно наблюдать в
таблице 1.1, составленной [14].
Таблица 1.1. Зависимость степени интеграции от метода связи
|
Метод создания связи
|
Степень автоматизации
|
|
Ручная
|
Автоматизированная
|
Автоматическая
|
|
Уровень брокеров
|
Отсутствует
|
Допускается
|
Предпочтительная
|
|
Уровень данных
|
Допускается
|
Допускается
|
Предпочтительная
|
|
Уровень сервисов
|
Допускается
|
Предпочтительная
|
Допускается
|
|
Уровень интерпретирования метаинформации
|
Допускается
|
Допускается
|
Предпочтительная
|
.2 Методы
передачи данных между ИС
На основании работ В.В. Абрамова [3] и А.А. Кусова [10] были выбраны
следующие методы интеграции ИС разных уровней для дальнейшего анализа:
1) обмен плоскими файлами;
) общая база данных;
) прямая связь систем;
) централизованный брокер сообщений;
) интеграционная шина.
.2.1 Обмен
плоскими файлами
Применение механизмов экспорта/импорта плоских файлов (Flat Files)
является одним из самых быстрых и дешевых способов интеграции данных ИС, с
точки зрения программной реализации и стоимости. Принцип метода прост -
система-отправитель импортирует файл заданного формата, а система-получатель
загружает его (рисунок 1.1). Передаваемый файл может храниться на локальном
компьютере или на сетевом ресурсе.
Рисунок 1.1. Схема обмена плоскими файлами
Самым распространенным форматом данных для данного метода является XML по
причине его поддержки многими производителями программного обеспечения:
Microsoft, Oracle, SUN и т.д. Но зачастую для сложных структур данных на
сегодняшний день используют JSON, в силу его удобочитабельности и лаконичности
при меньшем объеме файла, чем у XML.
Самым главным плюсом данного метода является простота его реализации, так
как практически любая современная система может принимать файлы. К минусам же
можно отнести ненадежность и асинхронность. Чтобы узнать о том, что файл
выгружен системе необходимо опрос директории, и, в случае потери файла,
необходимо повторно загружать данные. Еще одним недостатком является
ориентированность данного метода на передачу данных с большими интервалами
времени. При частом обращении к файловой системе скорость работы значительно
падает.
.2.2 Общая
БД
Метод подразумевает создание объединенного хранилища однородных данных,
независимого от бизнес-логики приложений (рисунок 1.2). Сегодня данный способ
очень популярен, но имеет множество недостатков, самый очевидный из которых это
разнородность информации из большого количества систем.
Рисунок 1.2. Схема общей БД
Преимуществом данного подхода является, разумеется, полная актуальность
данных, практически в реальном времени. Основным же недостатком является то,
что метод сложно реализуем, если уже существуют системы со своими БД. Мало того,
что для реализации потребуется объединить неоднородные данные из разных БД, так
и требования к новой БД будут очень высоки. Например, многие системы работают
только с БД определенного разработчика: MS SQL, Oracle и т.д.
1.2.3 Прямая связь систем
Прямое соединение систем или соединение «точка-точка» является наиболее
простым подходом и зачастую интеграционные проекты на начальной стадии
используют именно его. Для прямого соединения системам необходимо знать точную
адресную информацию о друг друга и уметь преобразовывать форматы данных,
используемых партнерами. Интеграция типа точка-точка часто означает разработку
и встраивание дополнительного программного обеспечения как минимум для одного,
а чаще для обоих взаимодействующих приложений.
Для упрощения разработки дополнительного ПО часто используются
специализированные выделенные программные компоненты: адаптеры и брокеры.
Адаптеры обеспечивают преобразование специфических интерфейсов и данных
конкретного приложения в интерфейсы и данные стандартной интеграционной среды.
Настройка интерфейсов, адресной информации и процедур трансформации вместо
написания кода позволяют ускорить внедрение интеграционного решения.
1.2.4 Централизованный брокер сообщений
Централизованный брокер сообщений представляет собой узел, к которому
обращаются интегрируемые системы (рисунок 1.3). Брокер перераспределяет,
обрабатывает и направляет потоки сообщений и данных из систем. Централизованная
реализация функций обработки передаваемой информации и данных ведет к выделению
репозитория общих интеграционных правил, что позволяет эффективно и динамически
сопрягать приложения в единую среду.
Рисунок 1.3. Схема использования централизованного брокера
1.2.5 Интеграционная шина
Метод подразумевает передачу сообщений через интеграционную шину, которая
берет на себя задачу адаптации и преобразования данных (рисунок 1.4). При
данном подходе, доработки в существующих системах сводятся к минимуму.
Данный метод основывается на сервис-ориентированной архитектуре
(Service-Oriented Architecture, SOA). На сегодняшний день это самый передовой
метод интеграции. Можно рассматривать SOA как парадигму, предназначенную для
проектирования и разработки приложений компании не просто как новый код с
обособленными функциями, а как связанный набор независимых друг от друга
сервисов. Это значит, что разработчики должны не просто работать в рамках своих
приложений, им необходимо подумать, какие уже существующие сервисы можно
использовать и как другие приложения могут использовать их сервис.
Рисунок 1.4. Схема интеграционной шины
Основным преимуществом данного метода является минимальные изменения или
их полное отсутствие в исходных системах. Также привлекает его масштабируемость
и универсальность, благодаря использованию множества интерфейсов. Недостатком
же является необходимость самой разработки шины, так как на это потребуется
время и ресурсы.
1.3 Анализ интегрируемых ИС
.3.1 Информационная среда ПНППК
ПАО «Пермская Научно-производственная Приборостроительная Компания»
(ПНППК) имеет многолетний опыт разработки и производства навигационных систем
различного назначения и товаров народного потребления. Важнейшими направлениями
ее деятельности являются: авиационное приборостроение, разработка и изготовление
изделий морской и наземной техники.
Прогрессивные технологии производства современных базовых элементов
гироскопических систем позволяют постоянно модернизировать существующее
навигационное оборудование и разрабатывать новые изделия с повышенной точностью
и расширенными возможностями. С привлечением лучших научно-технических сил
региона и России специалисты ПНППК освоили технологии производства
волоконно-оптических гироскопов. При освоении технологий производства
специальных видов оптоволокна освоено производство сверхпрочного оптоволокна,
оптоволокна для волоконно-оптических гироскопов и целая гамма датчиков на
оптоволокне.
Современные информационные технологии в настоящее время обеспечивают
управление всеми основными и поддерживающими процессами и основаны на
современных программных продуктах ARIS, SAP R/3, Pro/Engineer и прочие.
В ПНППК до 2000 года существовала «лоскутная автоматизация», то есть
различные бизнес-процессы были автоматизированы в рамках различных программных
средств, слабо или средне интегрированных между собой, и функционировали
достаточно автономно друг от друга.
Начиная с 2000 года, Компания ориентирована на разработку и внедрение
корпоративных информационных систем, интегрированных между собой.
На сегодняшний день базовыми являются системы:
- ARIS - система бизнес-моделирования, разработчик IDS-Scheer;
- SAP R/3 - ERP-система, разработчик компания SAP;
- Proingener - CAD\CAM\CAE - система автоматизированного
проектирования;
- Search - система электронного конструкторско-технологического документооборота
Компании;
- LanDocs - система электронного организационно-распорядительного документооборота
Компании, разработчик ЗАО «Ланит», г.Москва.
Единую архитектуру информационной среды предприятия можно увидеть в
приложении А.
.3.2
Система SAP R/3
SAP R/3 - это система класса ERP, разработанная компанией SAP SE.система
- это набор интегрированных приложений, позволяющих создать ИС для
автоматизации планирования, учета, контроля и анализа всех основных
бизнес-операций предприятия [9].R/3 состоит из ядра и прикладных модулей
(рисунок 1.5), отвечающих за различные бизнес-процессы компании (например, FI -
финансы, PP - планирование производством и т.д.) и интегрирующих их в реальном
времени. Система предназначена для полной автоматизации крупных и средних
компаний и, по оценке экспертов в области информационных технологий, является
ведущей на рынке ERP-систем [20].
Рисунок 1.5. Структура SAP R/3
R/3 способен настраиваться под определенные нужды компании. Система содержит
внутренний язык программирования (ABAP) и средства разработки и отладки - то
есть, при желании, в рамках системы можно разработать собственный функционал
или существенно расширить существующий и компания в последствии сможет работать
практически с индивидуальной версией системы, что увеличивает ее
продуктивность.
Система имеет трехуровневую архитектуру (цифра 3 из названия R/3),
состоящую из презентационного уровня, уровня приложений и уровня данных
(рисунок 1.6).
Презентационный уровень отвечает за диалог с пользователем, ввод и вывод
данных. Основан на последовательности окон, отражающих выполняемый
пользователем процесс (SAP GUI, Graphical User Interface). Может запускаться с
персонального компьютера пользователя.
Уровень приложений состоит из рабочих процессов, отвечающих за обработку
информации в соответствии с заданными правилами бизнеса, формируются служебные
функции для доступа к БД. Процессы могут быть распределены между несколькими
серверами. Сервер приложений также содержит диспетчера, который распределяет
поступающие задачи и контролирует их исполнение.
Рисунок 1.6. Архитектура SAP R/3
Уровень данных состоит из СУБД, где хранятся все данные системы.R/3
изначально позиционировала себя как система, имеющая высокие интеграционные
способности. Так в системе реализована технология RFC (Remote Function Call),
проприетарный интерфейс SAP, который позволяет удалено вызывать функции R/3
через функциональные модули BAPI (Business Application Programming Interface).
Коммуникация R/3 может происходить с другой как SAP-системой, так и
не-SAP-системой. Основан RFC на TCP/IP.
.3.3
Система «База производства ВОГ»
«База производства ВОГ (волоконно-оптических гироскопов) - это
веб-система, разработанная компанией «Восходящие технологии» для кластера ВОГ
ПНППК в 2014 году.
За последние два года «База производства ВОГ» стала основным инструментом
хранения, обработки и анализа информации кластера ВОГ. В базу попадают данные
со станков, пультов приемо-сдаточных испытание, операторов и технологов. На
выходе технологи, инженеры и руководство ПНППК получают отчётность и аналитику,
паспорта изделий, контроль процессов.
«База производства ВОГ» разработана на ASP.NET MVC, и она поддерживает
технологию REST
API (Representational State Transfer) в основном для выгрузки данных
в формате JSON (JavaScript Object Notation).
REST является альтернативой SOAP (Simple Object Access Protocol),
учитывая тот факт, что он является архитектурным стилем, а не протоколом или
стандартом, в отличие от SOAP. Основным преимуществом REST перед SOAP это его
простота как в структуре, так и в реализации. Стиль REST заключается в
соблюдении следующих принципов:
1) каждый объект имеет идентификатор;
) объекты ссылаются друг на друга;
) используются стандартные методы http;
) возвращаемые данные могут иметь различные форматы.
Благодаря последнему принципу API «Базы производства ВОГ» передают данные
в формате JSON, а не в популярном XML.- это простой формат обмена данными,
основанный на подмножестве языка программирования JavaScript [19]. В отличие от
XML, он легко читаем не только компьютером, но и человеком, что облегчает
ручную обработку данных. JSON - текстовый формат, независимый от языка
программирования, но он использует соглашения, знакомые программистам C-подобных
языков, таких как C, C++, C#, Java, JavaScript, Perl, Python и многих других.
1.4 Сравнение методов интеграции ИС
Рассмотрев особенности подходов к интеграции и специфику систем, выделим
преимущества и недостатки каждого подхода (табл. 1.1).
Таблица 1.2. Достоинства и недостатки методов расчета
показателя ПР
|
Метод интеграции ИС
|
Достоинства
|
Недостатки
|
|
Плоский файл
|
1. Низкие трудозатраты на реализацию. 2. Прозрачность
процесса. 3. Минимальная доработка систем.
|
1. Ориентирован на передачу данных с большим интервалом
времени. 2. Не позволяет оперативно реагировать на сбои при передаче. 3.
Уменьшение эффективности при масштабировании.
|
|
Общая БД
|
1. Полная актуальность данных.
|
1. Плохо масштабируема. 2. Большие требования к БД
(стандарты, производители и т.д.). 3. Объединение уже существующих БД.
|
|
Прямая связь систем
|
1. Простота реализации.
|
1. Необходимость разработки дополнительного ПО внутри
систем.
|
|
Централизованный брокер сообщений
|
1. Доработки в существующих системах сводятся к минимуму.
2. Перенос обработки информации из систем.
|
1. Необходимость разработки дополнительного ПО
|
|
Интеграционная шина
|
1. Доработки в существующих системах сводятся к минимуму.
2. Обширный набор интерфейсов. 3. Стандартизированность.
|
1. Дополнительная разработка (только если одна из систем
сама не может являться шиной). 2. Носит долгосрочный характер (рассчитан на
большие интеграционные проекты). 3. Интегрируемые системы не разработаны для
SOA архитектуры.
|
Разработка подходов централизованного брокера и интеграционной шины
являются предпочтительнее, чем прямое соединение, передача плоских файлов или
объединение БД. Несмотря на преимущества использования интеграционной шины
перед централизованным брокером в своей стандартизированности и идеологии,
первый подход носит слишком долгосрочный и сложный характер.
Таким образом было решено разработать централизованного брокера сообщений
в виде программного модуля, который, используя API систем принимает от них данные, преобразует и
переадресовывает их. В дальнейшем будет рассматриваться именно этот подход.
1.5 Анализ аналогичных решений
.5.1 SAP
PI
В своей работе Д.Ю. Степанов [11] рассматривает готовое решение SAP PI от
компании SAP SE как инструмент интеграции корпоративных ИС.PI (Process
Integration) - это интеграционный компонент платформы SAP NetWeaver
представленный в 2010 году. Его задачей является обеспечение совместной работы
разнородных ИС компании, не только продуктов SAP.PI разворачивается на уровне
приложений (рисунок 1.6) и его ядром является интеграционный сервер (рисунок
1.7). Он фактически является реализацией интеграционной шины и предлагает
типичные его функции, включая преобразование сообщений, их маршрутизацию,
механизмы публикации и подписки (рисунок 1.8).
Рисунок 1.7. Архитектура SAP PI
Для взаимодействия с внешними системами SAP PI использует адаптеры на
базе JCA (Java EE Connector Architecture). Структура адаптеров работает на
платформе J2EE (Java 2 Enterprise Edition) сервера приложений SAP NetWeaver
Application Server, и имеет собственные сервисы построения очередей и журналов.
Механизм адаптеров основан на структуре адаптеров и содержит JCA-совместимый
ресурсный адаптер. В инфраструктуру обмена SAP NetWeaver PI входят адаптеры:
- JDBC Adapter;
- JMS Adapter;
- File/FTP Adapter;
- SOAP Adapter;
- HTTP(s) Adapter;
- RFC Adapter;
- IDoc Adapter.
.
Рисунок 1.8. Модель технологии SAP PI
Учитывая, что одна из интегрируемых систем является также продуктом SAP,
данное решение выглядит достаточно целесообразно. Однако, как было замечено SAP
PI является по сути интеграционной шиной, и очень дорогой интеграционной шиной.
Помимо приобретения лицензии SAP NetWeaver, необходимо оплачивать работу
компонента PI отдельно, основываясь на объеме передаваемых данных.
.5.2
Использование SAP .NET Connector
На портале SAP Х. Гупта [16] описывает процесс передачи данных из С#
программы в хранилище данных SAP R/3 с помощью SAP .NET Connector 3.0..NET Connector
- это разработка компании SAP для коммуникации Microsoft .Net платформ и систем
SAP, поддерживающая RFC и Web-интерфейсы..NET Connector представляет собой
библиотеку классов, которая обрабатывает поступающий от программы запрос и
преобразует его формат для передачи по RFC протоколу в SAP систему и наоборот
(рисунок 1.9).
Рисунок 1.9. Модель технологии SAP .NET Connector
.5.3
Сравнение аналогов
Данные технологии находятся в разных категориях: SAP PI является крупным продуктом, развертыванием которого
занимаются профессионалы, а SAP .Net Connector является инструментом для
интеграционного решения. Таким образом, их сравнение по сути является
сравнением между приобретением готового решения и собственной разработкой. В
таблице 1.3 указаны достоинства и недостатки каждого аналога.
Таблица 1-1.3. Сравнение SAP PI и SAP .Net Connector
|
Достоинства
|
Недостатки
|
|
SAP PI (готовое решение)
|
1. Снижение стоимости разработки и поддержки процессов
интеграции; 2. Возможность объединения разнородных систем на базе
универсального формата обмена данными; 3. Мощный инструмент для последующих
проектов внедрения интеграционных решений (корпоративный портал, управление
НСИ, управление знаниями).
|
1. Представляет собой крупный проект, следовательно,
интеграция займет много времени; 2. Необходимость приобретения лицензии; 3.
Оплата по факту передачи информации.
|
|
SAP .Net Connector (собственная разработка)
|
1. Имеется в наличии; 2. Позволяет работать с BAPI,
RFC-функциями и IDoc из любого
.NET-приложения;
|
1. Необходима разработка; 2. Связь только с .Net приложениями.
|
Несмотря на то, что SAP PI выглядит
предпочтительно в плане функционала и отсутствия разработки, он стоит
достаточно крупных финансовых затрат. Таким образом, была выбрана собственная
разработка с использованием SAP .Net Connector.
Таким образом, в результате анализа проблемы интеграции КИС и подходов к
ее решению, а также анализа интегрируемых систем, был выбран подход
централизованного брокера сообщений. При сравнении аналогичных решений было
решено использовать в разработке библиотеки SAP для связи .Net приложений с R/3 SAP .Net Connector.
2. Интеграционное решение в бизнес-процессах ПНППК
.1 Анализ бизнес-процесса планирования и управления
производством
Как можно увидеть на карте процессов предприятия (рисунок 2.1), в
управлении всеми видами процессов (основными, управляющими и поддерживающими),
в их интеграции, создании единого информационного пространства предприятие
использует SAP R/3.
Одним из центральных бизнес-процессов является планирование и управление
производством. Данный процесс рассчитывает и прогнозирует цели и этапы процесса
производства при различных изменениях.
Рисунок 2.1. Карта процессов ПНППК [1]
На рисунке 2.2 можно увидеть декомпозицию бизнес-процесса “Планирование и
управление производством”.
Процесс планирования продаж, или планирования спроса, охватывает будущие
потребности без учета запасов и имеющихся мощностей. История продаж часто
служит основой для их планирования.
Рисунок 2.2. Декомпозиция процесса «Планирование»
В процессе управления спросом уже корректируется план продаж с учетом
требований заказчика в соответствии со стратегией планирования, и таким образом
формируется план реализации и производства.
Планирование потребности в материалах (ППМ) (рисунок 2.3) является
центральной функцией планирования производства. Она вычисляет количество
компонентов для покрытия всех уровней ППМ, на основе плана производства, а также
учитывая информацию из основных данных (технических карт, спецификаций, рабочих
мест): время выполнения заказа, размеров требуемых партий компонентов, и
количества лома. Результатом являются плановые заказы на материалы собственного
изготовления, либо заявки на сырье и покупные полуфабрикаты.
Плановый заказ - это количество конкретной детали (узла, изделия),
которое планируется изготовить к заданной дате. В основном он имеет силу
рекомендации.
Одним из важных этапов ППМ является календарное планирование. Календарное
планирование осуществляется на базе операций технологической карты и количества
планового заказа. Сроки, как правило, рассчитываются от конечных, начиная с
даты потребности, когда этот материал требуется. Таким образом, определяются
сроки начала и конца отдельных операций и заказа в целом, а также производится
расчет загрузки мощностей. На рисунке 2.4 проиллюстрировано календарное
планирование в виде диаграммы Ганта.
Рисунок 2.3. Диаграмма окружения функции планирования
потребности в материалах
Рисунок 2.4. Диаграмма Ганта календарного планирования
Долгосрочное планирование моделирует процесс ППМ и исследует, как
изменение плановых первичных потребностей будет влиять на загрузку
производственных мощностей, запасов и внешних закупок.
Центральным звеном в контроле и учете производственного процесса является
производственный заказ. Он может быть получен путем преобразования планового
заказа. Производственный заказ уже имеет обязательный характер, то есть
подразумевает количество конкретной детали (узла, изделия), которое необходимо
изготовить к определенной дате.
Процесс планирование мощностей, или планирование рабочей силы, детально
использует технические карты, в которых прописаны процессы производства
материала. Планирование мощностей позволяет распределить нагрузку на рабочих и
станки для более эффективного производства.
2.2 Анализ процесса исследования неисправных изделий
Процесс исследования неисправных изделий на предприятии регламентируется
стандартом о “Технологии исследования изделий, отказавших у потребителя и в
процессе производства” [2].
Основной формой исследования и устранения неисправностей изделий в ПНППК
является карточка учета неисправности (КУН). Она заводится на начальных этапах
и участвует в каждом последующей процессе. В карточке указывается основная
информация (приложение В), необходимая для исследования и ведения статистики:
информация по изделию, место обнаружения неисправности, программа исследования,
виновник дефекта и т.д.
Согласно стандарту, карточки учета неисправностей делятся на несколько
типов:
. КУН на изделие, отказавшее у потребителя - формируется в случае
поступления рекламации от компании покупателя изделия и подтверждении дефекта
специалистом ПНППК.
. Производственная КУН - формируется, когда неисправность в
изделии обнаружена на любом этапе его производства (первое включение, испытания
и т.д.).
. КУН на составную часть - формируется при выявлении отказа
компонента изделия и необходимости его дальнейшего исследования. Является по
сути производной от первых двух, так как инициировать исследование она не
может.
Процесс исследования, согласно стандарту, можно разделить на следующие
этапы:
. Формирование учетного дела на отказавшее изделие.
. Анализ сопроводительной документации.
. Первое включение изделия для подтверждения дефекта.
. Исследование отказавшего изделия.
. Разработка мероприятий по устранению и предупреждению причин
появления дефектов в изделиях.
. Оформление и утверждение итогового документа по результатам
исследования.
. Сбор, учет и хранение информации об отказавших изделиях.
. Анализ статистических данных и формирование отчетных документов
по отказам.
Жизненный цикл КУН начинается на этапе формирования учетного дела и
заканчивается на утверждении итогового документа исследования.
Существуют отличия в ведении КУН на изделие, отказавшее у потребителя, и
производственной КУН в данных этапах. Так, для производственных КУН отсутствуют
процессы анализа сопроводительной документации и первого включения, что
логично, так как документация отсутствует, а в первом включении нет
необходимости. На рисунке 2.5 можно видеть диаграмму окружения функции
исследования изделий, отказавших у потребителя и в процессе производства, а в
приложении Б ее декомпозицию.
Платформой для исследования неисправных изделий на данный момент является
модуль учета неисправностей навигационных систем (МУННС) в системе «База
производства ВОГ». Модуль имеет возможность вести электронные КУН, обеспечивая
гибким механизмом их согласования с ответственными лицами и формируя по ним
отчетность.
Принцип работы с электронными КУН основан на их переходе в различные
статусы, отражающие текущее состояние КУН. Статусы и переходы КУН
продемонстрированы на рисунках 2.6-7.
Рисунок 2.5. Диаграмма окружения функции "Исследование
изделий, отказавших у потребителя или в процессе производства”
Рисунок 2.6. Статусы и переходы производственных КУН и КУН на
составные части
Рисунок 2.7. Статусы и переходы КУН на изделия, поступившие
от заказчика
Правила перевода между статусами задаются следующим образом:
. Исходный статус → Конечный статус.
. Проверка заполнения обязательных полей.
. Какая роль имеет права на данный перевод.
Если для связки «Исходный статус → Конечный статус» отмечена опция
обязательное согласование, то перед переводом строки в новый статус инициатор
перевода должен указать перечень согласующих лиц.
Список согласующих может произвольно меняться инициатором в процессе
согласования. Список согласующих на каждой конкретной стадии формируется
согласно стандарту о «Технологии исследования изделий, отказавших у потребителя
и в процессе производства» [2].
При формировании списка согласования инициатор для каждого исполнителя
указывает тип действия (согласование, утверждение, принять в работу, на
ознакомление) и комментарий инициатора. По умолчанию комментарий к каждому
сообщению формируется автоматически в зависимости от типа действия (таблица
2.1).
Таблица 2.1. Стандартные комментарии для типов действия
|
Тип действия
|
Комментарий по умолчанию
|
|
Согласование
|
Прошу согласовать
|
|
Утверждение
|
Прошу утвердить
|
|
Принять в работу
|
Прошу принять в работу
|
|
На ознакомление
|
Прошу ознакомиться
|
Инициатор процесса согласования имеет опцию «Автоматически перевести в
конечный статус по окончании согласования».
2.3 Место анализа КУН в процессе планирования и управления
производством
Важность процесса исследования отказавших изделий заключается не только в
качестве послепродажного обслуживания изделий, что, по словам Захарова А.,
“катастрофически недооценено в нашей стране” [6], но и в использовании
результатов этапа анализа статистических данных для принятия управленческих
решений и более точного планирования производства.
Управленческие решения могут касаться различных аспектов, например,
возврат партий покупной продукции в случае обнаружения в ней определенной доли
брака и возможный пересмотр удовлетворенности поставщиком, отзыв собственной
продукции при определенной доли брака в партии, премирование или депремирование
подразделений и др.
Так как в случае обнаружения брака изделие может не подлежать ремонту,
или на время исследования потребуется списание запаса, данные отчетов по КУН
могут быть использованы в планировании производства, конкретно в процессе
планирования потребности в материалах для изменения запасов изделий на складе и
формирования дополнительных объемов производства. На рисунке 2.8 изображена
декомпозиция этого процесса с внедрением использования результатов анализа
данных по КУН.
В результате анализа бизнес процессов планирования производства и
исследования отказавших изделий было выяснена потребность подпроцесса
планирования потребности в материалах в результатах исследования отказавших
изделий - карточке учета неисправностей.
Рисунок 2.8. Диаграмма окружения функции планирования
потребности в материалах с внедрением интеграционного решения
3. Разработка интеграционного решения
.1 Проектирование интеграционного решения
.1.1 Структура данных в МУННС
Центральным объектом в МУННС, как и в исследовании неисправных изделий в
принципе, является КУН, точнее таблица «КУН.Карточка». Входящие в нее поля
перечислены в приложении В.
В карточке одним из обязательных полей является «№ изделия», которое
указывает, в каком изделии была обнаружена неисправность. Данное поле является
справочником и берет свои данные из таблицы «Изделия ПНППК». Изделия могут быть
произведены разными заводами-изготовителями (цехами), и каждый из них ведет
свой перечень изделий по ряду разных причин. Таким образов, таблица «Изделия
ПНППК» формируется за счет наполнения данными из таблиц изделий
заводов-изготовителей (цехов). В таблице 3.1 можно увидеть структуру таблицы
«Изделия ПНППК».
Таблица 3.1. Структура таблицы "Изделия ПНППК"
|
Поле
|
Тип поля
|
|
ID
|
Строка
|
|
ID_Source
|
Строка
|
|
Тип изделия ПНППК
|
Справочник
|
|
Номер изделия
|
Строка
|
|
Дата выпуска изделия
|
Дата
|
|
Тип производства
|
Справочник
|
В перечне полей таблицы «КУН.Карточка» присутствуют два поля с указанным
типом - таблица. Это поля «Программа исследования» и «Мероприятия по устранению
дефектов», которые являются вложенными таблицами, берущими данные из таблиц
«КУН.Программа исследования» и «КУН.Мероприятия по устранению дефектов» соответственно.
В таблицах 3.2-3 приведены структуры этих таблиц.
Таблица 3.2. Структура таблицы "КУН.Программа
исследования"
|
Поле
|
Тип поля
|
|
ID строки
|
Автоинкрементен. Уникальное
|
|
№ Карточки
|
Справочник
|
|
№ пункта по порядку
|
Целое число
|
|
Что требуется сделать?
|
Текст
|
|
Срок выполнения
|
Дата
|
|
Ответственный исполнитель
|
Справочник
|
|
Результат
|
Текст
|
Таблица «КУН.Программа исследований» состоит из записей действий, которые
необходимо сделать в рамках программы исследования дефекта изделия. Это
действие записывается в поле «Что требуется сделать?». Каждая такая запись
имеет номер КУН, к программе исследований которого она относится.
Таблица 3.3. Структура таблицы "КУН.Мероприятия по
устранению дефектов"
|
Поле
|
Тип поля
|
|
ID строки
|
Автоинкрементен. Уникальное
|
|
№ Карточки
|
Справочник
|
|
Тип мероприятия (для НТЦ)
|
Справочник
|
|
Приоритет
|
Справочник
|
|
Описание мероприятия
|
Текст
|
|
Разработчик мероприятий
|
Справочник
|
|
Подразделение
|
Справочник
|
|
Отв. мастер
|
Справочник
|
|
Отв. контроллер
|
Справочник
|
|
Срок выполнения
|
Дата
|
|
Результат выполнения мероприятий
|
|
Дата выполнения мероприятий
|
Дата
|
Аналогично с записями в таблице «КУН.Мероприятия по устранению дефектов».
Каждая запись - это действие, которое необходимо сделать в рамках программы
мероприятий по устранению и предотвращению появления дефектов уже после
исследования и обнаружения дефекта. Она также содержит номер КУН, к которой
относится.
3.1.2 Структура передаваемых данных
Структура данных, которые будут передаваться из системы «База
производства ВОГ» в SAP R/3 определяется следующими факторами:
. Неисправные изделия должны однозначно определяется в SAP R/3.
. Должны передаваться только те данные, которые будут необходимы
для дальнейшего анализа в SAP R/3.
В своей работе SAP R/3 оперирует так
называемыми основными данными, включающими в себя основные записи материалов
(ОЗМ), технологические карты и спецификации. Для однозначного определения типа
изделий, узлов и компонентов (материалов) и предназначена ОЗМ. Таким образом
формируется задача соотнесения записей по изделиям из системы «База
производства ВОГ» и ОЗМ.
Идентификаторами ОЗМ выступают два атрибута материала: код материала -
для системы и децимальный номер - для пользователей, а идентификатором изделий
в «Базе производства ВОГ» - поле «Номер изделия». Ни одного из ключевых атрибутов
ОЗМ в записи изделий «Базы производства ВОГ» нет. Таблица «Изделия ПНППК»
содержит поле «Тип изделия» (приложение В), для которого ОЗМ по сути является
справочником. Возможностью соотнесения ОЗМ и типа изделия является сравнение
поля «Тип изделия» «Базы производства ВОГ» и поля «Краткое название» ОЗМ.
В этом случае встает проблема сравнения, так как автоматическое сравнение
невозможно из-за разных способов ввода, сокращений, регистра и т.д. Было
принято решение составления перекодировочной таблицы, которая бы использовалась
для преобразования записей изделий при занесении их в SAP R/3.
Для определения данных, необходимых для дальнейшего анализа было
проведено интервью с потенциальным пользователем, специалистом, отвечающим за
качество продукции. Также были проанализирована формируемая им отчетность. В
результате был сформирован следующий перечень необходимых данных (таблица 3.4):
. Наименование и оригинальный номер изделия.
. Наименование и оригинальный номер компонента.
. Дата забракования.
. Цех обнаружения дефекта.
. Участок обнаружения дефекта.
. Номер КУН.
. Количество забракованных изделий.
. Стадия отказа изделия.
. Результаты исследования.
. Дата возврата изделия.
. Дата закрытия КУН.
Таблица 3.4. Структура передаваемых данных для SAP R/3
|
Поле
|
Тип данных
|
|
№ КУН
|
CHAR
|
|
Цех/Плановик
|
CHAR
|
|
ВыпускУчасток
|
CHAR
|
|
Проявление дефекта
|
NUMC
|
|
Дата выписки
|
CHAR
|
|
Стадия отказа
|
CHAR
|
|
Изделие
|
CHAR
|
|
НомИзд
|
DATS
|
|
Компонент
|
CHAR
|
|
НомДет, узла
|
INT4
|
|
Статус
|
CHAR
|
|
Результат исследования
|
CHAR
|
|
Классификация дефекта
|
CHAR
|
|
Дата классификации
|
CHAR
|
|
ДатаЗакрКУН
|
CHAR
|
|
ДатаВозврИзд
|
CHAR
|
Данные по дате возврата изделия и закрытии КУН явно отсутствуют в перечне
полей КУН (приложение В). Таблица «КУН.Мероприятия по устранению дефектов»
содержит типовое мероприятие «Возвратить изделие в установленном порядке»,
поэтому датой возврата изделия будет является дата перехода записи «Возвратить
изделие в установленном порядке» определенного КУН в статус «Выполнено».
Согласно стандарту о «Технологии исследования изделий, отказавших у
потребителя и в процессе производства» [2], датой закрытия КУН можно считать
дату его согласования с главным контролером и директором по качеству. Данная
процедура согласования происходит в статусе «Утверждение КУН». Таким образом
датой закрытия КУН можно считать его переход из статуса «Утверждение КУН» в
статус «Выполнение мероприятий».
3.1.3 Проектирование функционала модуля
Разрабатываемый интеграционный модуль не будет иметь большого перечня
функций. Его работа будет заключаться в следующем:
1) получение данных по карточкам учета неисправностей из системы
“База производства ВОГ”;
) отправка данных по карточкам учета неисправностей в систему SAP
R/3;
) обработка данных.
Как уже было сказано, в системе “База производства ВОГ” реализован REST
API, который позволяет совершать любые действия с системой не только через
интерфейс, но и через программный вызов соответствующих HTTP методов. Работа с
API системы происходит по протоколу HTTP в формате JSON. Перечень с имеющимися
API системы “База производства ВОГ” можно увидеть в приложении Г. Для функции
обмена данными целесообразно использовать эти API, так как не потребуется
дополнительная разработка.
Как видно в перечне API
системы «База производства ВОГ» (приложения Г), каждый API требует
идентифицирующий токен пользователя в заголовке метода. Для определения токена
пользователя изначально требуется вызвать API «Login» с указанием своего логина
и пароля:
{ "Login": "логин",
"Password": "пароль" }
Процесс получения и отправки данных по карточкам учета неисправностей
будет происходить следующим образом (рисунок 3.1):
1) пользователь вводит свои логин и пароль от систем «База
производства ВОГ» и SAP R/3;
) модуль получает идентифицирующий токен в системе «База
производства ВОГ» с помощью API «Login»;
) модуль с помощью токена использует API для получения данных из системы «База производства
ВОГ»;
) модуль получает данные;
) модуль преобразует данные;
) модуль устанавливает соединение с BAPI SAP R/3;
) модуль отправляет данные в систему SAP R/3.
Рисунок 3.1. UML диаграмма последовательности процесса
получения и отправки данных по карточкам учета неисправностей
Процесс обработки данных подразумевает под собой сериализацию и
десериализацию данных в зависимости от системы, с которой происходит
соединение: с “Базой производства ВОГ” это, как уже было сказано, JSON, с SAP
R/3 - IDос (Intermediate Document).
Документы IDoc являются контейнерами для обмена данными в
предустановленном формате в SAP системе, между SAP системами и между SAP и
не-SAP системами. Тип IDoc может передавать несколько типов сообщений. IDoc
используются для входящей и исходящей обработки. Адаптер поддерживает простой и
расширенный типы IDoc.
Не SAP-системы могут использовать IDoc в качестве стандартного интерфейса
для передачи данных. IDoc похож на XML по назначению, но отличается
синтаксисом. Оба служат для обмена данными и автоматизации в компьютерных
системах, но у них есть различия. Например, XML имеет древовидную структуру,
содержащую данные и метаданные, IDoc использует таблицы.
3.1.4 Архитектура интеграционного решения
На рисунке 3.2 можно увидеть архитектуру разрабатываемого интеграционного
решения.
Рисунок 3.2. Архитектура интеграционного решения
3.2 Реализация интеграционного решения
.2.1 API в «Базе производства ВОГ»
Как уже было сказано, для передачи данных по КУН из системы «База
производства ВОГ» в интеграционных модуль будут использоваться API данной системы. Из перечня API (приложение Г) видно, что для
просмотра таблиц подойдут «TableDataPage» и «TableStructure», первый возвращает записи таблицы,
а второй - метаданные и записи.
Однако, так как некоторые данные отсутствуют в таблице «КУН.Карточка»,
потребуется сложное тело запроса JSON.
Для избегания сложного тела запроса со стороны разработчиков системы «База
производства ВОГ» был разработан табличный отчет, формирующийся SQL-запросом и содержащий все
согласованные данные. Но для передачи записей данного отчета будет
использоваться API «ViewStructure».
3.2.2 BAPI в SAP R/3
Со стороны SAP R/3 был разработан BAPI, задачей которого является прием
данных от интеграционного модуля, преобразование этих данных с помощью
кодировочной таблицы и сохранение их в таблицу «КУН (Карточка учета
неисправности)» в базе данных SAP R/3. Структура
таблицы соответствует структуре в таблице №.
BAPI
было дано системное имя ZBAPI_INSERT_CUN. Далее задан его дистанционный вид выполнения
(рисунок 3.3).
Рисунок 3.3. Задание свойств дистанционного функционального
модуля в SAP R/3
Программа модуля оперирует таблицей базы данных R/3 «КУН (Карточка учета неисправности)» (системное имя ZPP_0160) и загружаемыми данными:
tables: zpp_0160.: wa_itab like line of itab.
Все данные таблицы ZPP_0160
удаляются и заносятся заново с каждым вызовом модуля. Для связывания данных по
материалам (ОЗМ) в SAP R/3 с материалом, указанным в карточке
используется кодировочная таблица (wa_itab-nomizd_izd), занесенная в код:
perform convert_nomizd using wa_itab-nomizd_izd
changing zpp_0160-nomizd_izd.
3.2.3 Разработка интеграционного модуля
Интеграционным модулем будет являться консольное приложение C#, запускаемое с помощью пакетного
файла. Разработка будет вестись в Visual Studio 2013.
После создания проекта консольного приложения подключим используемые
библиотеки классов, которые на потребуются в будущем: библиотеки SAP .Net Connector и JSON.Net
(рисунки 3.4-5).
Рисунок 3.4. Подключение библиотек SAP .Net Connector
Рисунок 3.5. Подключение библиотек JSON
Запуск модуля через пакетный файл аргументирован тем, что в файле можно
указать параметры запуска, а именно логины и пароли от систем. Так как
ответственный за запуск сотрудник меняется, но редко, то внесение логинов и
паролей в код программы неудобен тем, что для изменений требуется разработчик,
а постоянный их ввод в консоль или форму занимает время.
Для начала заведем переменные для хранения логинов и паролей:
private static string lSapLogin = null;static string
lSapPassword = null;static string lCunLogin = null;static string lCunPassword =
null;
Присвоим переменным значения вводимых параметров:
static void Main(string[] args)
{ lSapLogin = args[0];
lSapPassword = args[1];
lCunLogin = args[2];
lCunPassword = args[3]; }
Для дальнейшего получения пользовательского токена и данных по КУН из
системы «База производства ВОГ» необходимо разработать метод, вызывающий API в данной системе. Метод будет
универсальным и будет принимать три аргумента: URL, тело запроса и используемый HTTP метод (по умолчанию POST).
public static dynamic SendApiCall<T>(string url,
T request, bool isPost = true) {}
В данной методе отправляется запрос по указанному URL и результат десериализуется из
формата JSON:
result = Client.PostAsJsonAsync(url,
request).Result;responseString =
result.Content.ReadAsStringAsync().Result;response =
JsonConvert.DeserializeObject(responseString); response;
Теперь необходимо только вызвать API “Login”
для получения токена, за тем внести его в заголовок запроса API и вызвать данные по КУН:
dynamic LoginResult = SendApiCall(Cun_Api_Log, new
LoginRequest()
{
Login = lCunLogin,
Password = lCunPassword
});Token =
LoginResult.Account.AccessToken;.DefaultRequestHeaders.Add("AuthToken",
Token);CunData = SendApiCall(Cun_Api_ViewStructure, reqJson);
Переменная reqJson имеет
класс ViewStructureRequest, описывающий структуру запроса:
class ViewStructureRequest
{
public long ViewId { get; set; }
public ViewDataPageRequest DataRequest { get; set; }
}
public class ViewDataPageRequest
{
public long ViewId { get; set; }
public int StartIndex { get; set; }
public int EndIndex { get; set; }
public IEnumerable<SortColumn> Sortings { get;
set; }
public TableFilter Filter { get; set; }
public IEnumerable<ViewFilterModel> Params {
get; set; }
}
Теперь, получив данные по КУН, необходимо подготовить их для передачи в
хранилище системы SAP R/3:
public class SapDataStructure
{
public DataTable SapDataTable = null;
public SapDataStructure()
{
DataTable tDataTable = null;
DataColumn tDataColum = null;
tDataTable = new
DataTable("CUN_DATA_TABLE");
tDataColum = new DataColumn();
tDataColum.ColumnName = "NUM_CARD";
tDataColum.DataType =
Type.GetType("System.String");
tDataColum.Caption = "№ карточки";
tDataColum.ReadOnly = true;
tDataTable.Columns.Add(tDataColum);
tDataColum = new DataColumn();
tDataColum.ColumnName = "STAD_FAIL";
tDataColum.DataType =
Type.GetType("System.String");
tDataColum.Caption = "Стадия отказа";
tDataColum.ReadOnly = true;
tDataTable.Columns.Add(tDataColum);
…
SapDataTable = tDataTable;
}
}static void PrepareDataCunTransfer()
{
DataRow DataRow = null;
SapDataTransferStructure = new
SapDataClass.SapDataStructure();
dynamic CunData = gclCunClass.Data.InitialData.Data;
foreach (var DataItem in CunData)
{
DataRow =
SapDataTransferStructure.SapDataTable.NewRow();
DataRow["NUM_CARD"] =
(string)DataItem["№ карточки"];
DataRow["STAD_FAIL"] =
(string)DataItem["Стадия отказа"];
…
SapDataTransferStructure.SapDataTable.Rows.Add(DataRow);
}
}
Теперь необходим метод, который бы помещал полученные данные в контейнер
и отправлял их, вызывая BAPI в
SAP R/3 по указанным параметрам:
public static void CallRfcCUN(string NameFunction,
RfcDestination SapRfcDest, RfcRepository SapRfcRep,
SapDataClass.SapDataStructure SapDataTransferStructure)
{
IRfcFunction lFunction =
SapRfcRep.CreateFunction(NameFunction);
IRfcTable SapTable =
lFunction.GetTable("Itab");
foreach (DataRow DataRow in
SapDataTransferStructure.SapDataTable.Rows)
{
SapTable.Append();
if (DataRow["NUM_CARD"] != DBNull.Value)
{
SapTable.SetValue("ZZCUN",
DataRow["NUM_CARD"]);
}
if (DataRow["STAD_FAIL"] != DBNull.Value)
{
SapTable.SetValue("STAGE_CANCEL",
DataRow["STAD_FAIL"]);
}
…
}
lFunction.Invoke(SapRfcDest);
}
Таким образом, было спроектировано интеграционное решение: структура
данных, функционал и архитектура. Также разработан его основной функционал с
помощью объектно-ориентированного языка программирования C#.
Заключение
Любая достаточно крупная компания не может ограничиться использованием
единственного программного продукта для своей деятельности, поэтому рано или
поздно встает проблема интеграции корпоративных систем. Сегодня достаточно
много готовых интеграционных решений, предоставляемых различными компаниями, но
зачастую их цена оказывается велика. Таким образом, компании склоняются к
собственной разработке интеграционных решений.
В рамках данной работы была поставлена цель автоматизировать процесс
отслеживания неисправных изделий в системе SAP R/3 с помощью ее интеграции с системой «База производства
ВОГ». Для достижения цели были выполнены нижеперечисленные задачи.
1. Изучена проблема интеграции КИС и методы ее решения. Методы
сравнены между собой, и было принято решение использовать подход
централизованного брокера сообщений.
. Проанализирована деятельность предприятия, а также ее
информационная среда, включающая в себя интегрируемые системы SAP R/3 и «База производства ВОГ».
. Проанализированы процессы планирования производством и
исследования неисправных изделий. Определена потребность результата
исследования неисправных изделий - КУН для процесса планирования потребности в
материалах.
. Проанализирована структура данных КУН в МУННС. Спроектирована
структура данных, которые будут передаваться в SAP R/3. Спроектирован основной функционал модуля и архитектура
всего интеграционного решения. Разработан основной функционал интеграционного
модуля.
Процесс внедрение данного интеграционного решения уже начат, но не может
быть закончен в полной мере до тех пор, пока в системе «База производства ВОГ»
не будет реализована электронная подпись карточек учета неисправностей. На
данный момент эти документы не имеют экономической силы и не могут быть
использованы для учета в системе SAP R/3.
Основные
обозначения и сокращения
1. БД - база данных.
2. ВОГ - волоконно-оптический гироскоп.
3. ИС - информационная система.
4. КУН - карточка учета неисправностей.
5. ПНППК - ПАО «Пермская научно-производственная приборостроительная
компания».
6. ПО - программное обеспечение.
7. СУБД - система управления базой данных.
Библиографический
список
1. ПР-001. Руководство по качеству. Нормативная
документация ПАО «Пермская научно-производственная приборостроительная
компания». - 2015.
. СТП-065. Технология исследования изделий, отказавших
у потребителя или в процессе производства. Нормативная документация ПАО
«Пермская научно-производственная приборостроительная компания». - 2015.
. Абрамов В.В. Механизмы интеграции систем. // ГОУВПО
«Мордовский государственный университет им. Н. П. Огарева». Саранск: МГУ им.
Н.П.Огарева, 2010.
. Вичугова А.А., Вичугов В.Н., Дмитриева Е.А., Цапко
Г.П. Методы и средства интеграции информационных систем в рамках единого
информационного пространства проектирования//Вестник науки Сибири. - 2012. - №5
(6) - С.113-117.
. Дикерсбах Й.Т., Келлер Г. Планирование и управление
производством с помощью решений SAP ERP. СПб: Эксперт РП, 2011.
. Захаров А. Управление производственными потоками с
использованием ERP-системы SAP при изготовлении машиностроительной продукции //
Журнал «Умное производство». - 2010. - №12.
. Использование типа dynamic (Руководство по
программированию на C#) // Сеть разработчиков MSDN [Электронный ресурс]. URL: https://msdn.microsoft.com/ru-ru/library/dd264736.aspx (дата обращения: 13.04.2017).
. Когаловский М.Р. Методы интеграции данных в информационных
системах // Институт проблем рынка РАН. М.: РАН, 2010.
. Кожухова О.А., Кукаревцев В.В. Внедрение и
использование ERP-систем на предприятии // Актуальные проблемы авиации и
космонавтики. - 2011. - №7 - С.448-449.
. Кусов А.А. Проблемы интеграции корпоративных
информационных систем // УЭкС. - 2011. - №28. - С.103-109.
. Степанов Д.Ю. Способы интеграции корпоративных
информационных систем. // Естественные и технические науки. - 2014. - №1 (69).
- С. 207-213.
. Франгулова Е.В. Классификация подходов к интеграции
и интероперабельности информационных систем // Вестник АГТУ. Серия: Управление,
вычислительная техника и информатика. - 2010. - №2. - С.176-180.
. Черняк Л. Интеграция данных: синтаксис и семантика
// Открытые системы. СУБД. - 2009. - №10.
. Щекочихин О.В., Шведенко П.В., Анализ уровней
интеграции компонентов гетерогенных информационных систем // Международный
журнал «Программные продукты и системы». - 2016. - №4. - С.73-77.
15. De R.B. SAP PI for Beginners [Электронный ресурс]// Blog SAP. URL: https://blogs.sap.com/2013/05/21/sap-pi-for-beginners/ (дата обращения: 13.04.2017).
16. Gupta H. Transfer Data from .NET to SAP using
SAP Dot NET connector 3.0. [Электронный ресурс] // Blogs SAP. URL: https://blogs.sap.com/2013/09/13/transfer-data-from-net-to-sap-using-sap-dot-net-connector-30/ (дата обращения: 13.04.2017).
17. Reddy A.K. SAP R/3 Architecture Explained. [Электронный ресурс]// SAPNuts.com. URL: https://www.sapnuts.com/courses/core-abap/sap-intro/sap-r-3-architecture.html (дата обращения: 13.04.2017).
18. SAP .NET Connector 3.0 Overview. [Электронный ресурс]// Logosworld. URL: #"897345.files/image023.jpg">
Рисунок А.1. Архитектура единой ИС"ПНППК"
Приложение
Б
Декомпозиция
процесса «Исследование изделия, отказавшего у потребителя или в процессе
производства»
Рисунок Б.1. Декомпозиция процесса исследования отказавших
изделий
Приложение
В
Структура
таблицы «КУН.Карточка» в МУННС
Таблица В.1. Поля таблицы "КУН.Карточка"
|
Группа полей
|
Поле
|
Тип поля
|
|
№ Карточки
|
Строка
|
|
Тип КУН
|
Справочник
|
|
№ системы
|
Справочник
|
|
№ прибора
|
Справочник
|
|
№ блока
|
Справочник
|
|
№ базового элемента
|
Справочник
|
|
Дата изготовления
|
Дата
|
|
Дата отказа
|
Дата
|
|
Изделие поступило
|
из
|
Справочник
|
|
Изделие поступило
|
от
|
Справочник
|
|
Изделие поступило
|
по документу
|
Справочник
|
|
Изделие поступило
|
дата документа
|
Дата
|
|
Изделие поступило
|
приемный акт №
|
Строка
|
|
Изделие поступило
|
дата приемного акта
|
Дата
|
|
Дата начала эксплуатации
|
Дата
|
|
Гарантийный срок эксплуатации
|
Вещественное число
|
|
Тип стадии отказа
|
Справочник
|
|
Стадия отказа
|
Справочник
|
|
Наработка, час.
|
Целое число
|
|
Восстановлен в эксплуатирующей организации
|
дата восстановления
|
Дата
|
|
Восстановлен в эксплуатирующей организации
|
№ изделия
|
Справочник
|
|
Восстановлен в эксплуатирующей организации
|
Замена по документу
|
Справочник
|
|
Восстановлен в эксплуатирующей организации
|
№ документа
|
Строка
|
|
Внешний воздействующий фактор
|
Справочник
|
|
|
Проявление дефекта
|
Справочник
|
|
|
Описание проявления дефекта
|
Текст
|
|
|
Дефект при первом включении
|
Строка
|
|
|
Ответственный за программу исследований
|
Справочник пользователей
|
|
|
Доп. разработчик программы исследований
|
Справочник пользователей
|
|
|
Ответственный за выполнение программы исследований
|
Справочник пользователей
|
|
|
Доп. исполнитель программы исследований
|
Справочник пользователей
|
|
|
Программа исследований
|
Таблица
|
|
|
Исследованием установлено
|
Текст
|
|
|
Рекомендации
|
Текст
|
|
|
Причина отказа (заключение)
|
Текст
|
|
|
Перечень вышедших из строя деталей
|
Текст
|
|
|
Классификация дефекта
|
Справочник
|
|
Виновник
|
Завод
|
Справочник
|
|
Виновник
|
Человек
|
Справочник
|
|
Виновник
|
Комментарий
|
Текст
|
|
|
Ответственный за разработку мероприятий
|
Справочник
|
|
|
Доп. разработчик мероприятий
|
Справочник
|
|
|
Мероприятия по устранению дефектов
|
Таблица
|
|
|
Ответственный за выполнение мероприятий
|
Справочник пользователей
|
|
|
Доп. исполнитель мероприятий
|
Справочник пользователей
|
Приложение
Г
Перечень API в системе «База производства ВОГ»
1. Login
Авторизация в системе.
Описание метода: Метод позволяет узнать свой AuthToken, для дальнейших
вызовом методов API. Данный токен не изменяется до тех пор, пока не измениться
пароль пользователя.
Тип метода: POST.
Вызов метода: http://[сервер]:[порт]/api/login/login
Тело запроса:
"Password": "пароль" }
Описание параметров запроса:
· Login - табельный номер или логин пользователя
· Password - пароль пользователя
Результат запроса:
{
"IsValid": true,
"Account": {
"Id": 1,
"Login": "user",
"Number": 1,
"AccessToken": "abcdef…",
…
}
}
2. TableDataPage
Описание метода: Получение записей таблицы.
Тип метода: POST. В заголовке запроса указывать AuthToken - аксесс
токен пользователя.
Вызов метода: http://[сервер]:[порт]/api/tabledata/tabledatapage
Тело запроса:
{
"TableId": 83,
"StartIndex": 0,
"EndIndex": 1000
}
Описание параметров запроса:
· TableId - идентификатор таблицы, из которой нужно получить данные
· StartIndex - индекс первой строки
· EndIndex - индекс последней строки
Результат запроса:
{
"Data": [
{
"SysId": 114,
"SysStatusId": 626,
"SysStatusId_fk": "Нововведения",
"SysInsUserId": 1,
"SysInsUserId_fk": "admin",
"SysInsDate": "2015-03-03T16:22:08.9",
"SysUpdUserId": 1,
"SysUpdUserId_fk": "admin",
"SysUpdDate": "2016-08-31T10:45:28.67",
…
},
...
],
"DenyColumns": [
{
"RowId": 114,
"DenyColumns": [
26845
]
},
...
],
"TotalRows": 764,
"StartRowIndex": 0,
"RowColors": []
}
3. TableStructure
Описание метода: Получение метаданных и данных таблицы.
Тип метода: POST. В заголовке запроса указывать AuthToken - аксесс
токен пользователя.
Вызов метода: http://[сервер]:[порт]/api/tabledata/TableStructure
Тело запроса:
{
"TableId": 83,
"DataRequest": {
"TableId": 83,
"StartIndex": 0,
"EndIndex": 1000
}
}
Описание параметров запроса:
· TableId - идентификатор таблицы, из которой нужно получить данные
· DataRequest - объект, который содержит список параметров для получения
данных. Если передать null, то метод вернет только метаданные таблицы.
· StartIndex - индекс первой строки
· EndIndex - индекс последней строки
4. AddRow
Описание метода: Добавление записи в таблицу.
Тип метода: POST. В заголовке запроса указывать AuthToken - аксесс
токен пользователя.
Вызов метода: http://[сервер]:[порт]/api/tabledata/addrow
Тело запроса:
{
"TableId": 83,
"Row": {
"1110": "Новая запись",
"-1": 626,
"26678": 2
}
}
Описание параметров запроса:
· TableId - идентификатор таблицы, в которую выполняется вставка строки
· Row
- объект строки, хранящий пары id столбца и значение ячейки.
Результат запроса:
{
"ErrorMessage": null,
"SysId": 866,
"Columns": {
"1110": "Новая запись",
"26678": 2
}
}
5. AddCellFile
Добавляет файлы к ячейке записи.
Вызов метода http://{serverName}/api/TableData/AddCellFile
Метод необходимо вызывать перед вызовом addrow.
Тип метода POST, заголовок AuthToken - аксесс токен
пользователя, получаемый им при логине в систему, Content-Type:multipart/form-data;.
В теле запроса надо послать содержимое файла. В результате выполнения запроса
будет получен ответ, содержащий id файла в системе (например: "с4a89cebe7624e4e94ed8e8d65g41e4b").
Далее данный файл можно указать в методе addrow для ячеек типа
файл.
{"Row" : {"1110" : "тестовое
предложение" , "2108" : null , "13189" : {
"с4a89cebe7624e4e94ed8e8d65g41e4b" : "3.jpg" } ,"-1"
: 649 } , "SysId" : null , "tableId" : 83 }.
Все остальные параметры метода addrow останутся неизменными. Метод addrow
может принимать произвольное количество файлов.
6. EditRow
Описание метода: Редактирование записи в таблице.
Тип метода: POST. В заголовке запроса указывать AuthToken - аксесс
токен пользователя.
Вызов метода: http://[сервер]:[порт]/api/tabledata/editrow
Тело запроса:
{
"SysId": "866",
"TableId": 83,
"Row": {
"1110": "Тест"
}
}
Описание параметров запроса:
· TableId - идентификатор таблицы, в которую выполняется вставка строки
· Row
- объект строки, хранящий пары id столбца и значение ячейки.
· SysId - id строки, которую изменяем
Результат запроса:
{
"ErrorMessage": null,
"SysId": 866,
"Columns": null
}
7. FkValuesForColumn
Описание метода: Получает список значений из управляющей таблицы. Учитывает
логику ограничений по статусам на внешние ключи, т.е. показывает те же данные
что и стандартный веб интерфейс.
Тип метода: POST. В заголовке запроса указывать AuthToken - аксесс
токен пользователя.
Вызов метода: http://[сервер]:[порт]/api/tabledata/fkvaluesforcolumn
Тело запроса:
{
"ColumnId": 26678,
"QueryText": "и"
}
Описание параметров запроса:
· ColumnId - id столбца, для которого нужно запросить список значений.
· QueryText - текст по которому фильтруются допустимые значение. Если указать пустой
текст, то получим все записи.
Результат запроса:
{
"ColumnId": 26678,
"Values": [
{
"Key": 2,
"Value": "ЗФиОП"
}
]
}
Описание параметров результата запроса:
· Key
- значение внешнего ключа (управляющий столбец).
· Value - значение для отображения в списках (столбец для отображения).
8. ViewDataPage
Описание метода: Получение записей табличного отчета.
Тип метода: POST. В заголовке запроса указывать AuthToken - аксесс
токен пользователя.
Вызов метода: http://[сервер]:[порт]/api/view/viewdatapage
Тело запроса:
{
"ViewId": "12762",
"StartIndex": 0,
"EndIndex": 1000,
"Sortings": [
{
"ColumnName": "WhiteZoneBuild",
"SortDirection": -1,
"SortType": 0
}
],
"Filter": {
"GroupType": 0,
"GroupItems": [
{
"GroupType": 0,
"GroupItems": [
{
"GroupType": null,
"GroupItems": null,
"ColumnId": 101889,
"Value": 2,
"Type": 1
}
]
}
]
},
"Params": [
{
"ParamId": 364,
"Values": [],
"DateValue": "2016-10-01T00:00:00.000Z"
},…
]
}
Описание параметров запроса:
· ViewId - id отчета, из которой нужно получить данные.
· StartIndex - индекс первой строки
· EndIndex - индекс последней строки
· Sortings - параметры для сортировки данных
· Filter - параметры для фильтрации данных
· Params - параметры отчета
Результат запроса:
{
"Data": [
{
"numberBuild": "7883-ааа",
"SysInsDateBuild": "2016-10-26T14:31:01.613",
"GrayZoneBuild": 2.22014,
"WhiteZoneBuild": 123,
"WorkTimeBuild": 123,
"CountReassBuild": 2,
"SysInsDateCheck": "2016-10-27T17:55:14.777",
"GrayZoneCheck": 1.375,
"WhiteZoneCheck": -1.3689,
"WorkTimeCheck": 0.0061,
"CountReassCheck": 1
},
...
],
"DenyColumns": null,
"TotalRows": 6,
"StartRowIndex": 0,
"RowColors": []
}
Описание параметров результата запроса:
· Data - данные отчетов.
9. ViewStructure
Описание метода: Получение метаданных и данных отчета.
Тип метода: POST. В заголовке
запроса указывать AuthToken - аксесс токен пользователя.
Вызов метода: http://[сервер]:[порт]/api/viewstructure
{
"ViewId": "1",
"DataRequest": {
"ViewId": "1",
"StartIndex": 0,
"EndIndex": 100,
"Sortings": null,
"Filter": null,
"Params": []
}
}
Описание параметров запроса:
· ViewId - id отчета.
Приложение
Д
Техническое
задание
1. Введение
.1. Наименование системы
Наименование программы - «Модуль интеграции систем SAP R/3 и «База производства ВОГ».
1.2. Краткая характеристика области применения
Программа предназначена для интеграции систем в информационной среде
Заказчика.
2. Основания для разработки
Разработка ведется на основании протокола № 66/68-238-п совещания по
организации взаимодействия SAP R/3 и базы
производства ВОГ от 24.10.2016 г.
Протокол согласован с заместителем генерального директора по науке
(директором научно-технического центра) ПАО «Пермская научно-производственная
приборостроительная компания» А.В. Субботиным и утвержден директором по ИТ М.И.
Заком, именуемым в дальнейшем Заказчиком, того же предприятия.
3. Назначение разработки
.1. Функциональное назначение
Программа должна интегрировать системы SAP R/3 и База производства ВОГ в части отслеживания неисправных
изделий.
3.2. Эксплуатационное назначение
Программа должна эксплуатироваться системами SAP R/3 и База производства ВОГ в автоматическом режиме.
Конечными пользователями должны являться пользователи систем SAP R/3 и База производства ВОГ.
4. Требования к программе
.1. Требования к функциональным характеристикам
4.1.1. Требования к составу выполняемых функций
Программа должна выполнять перечисленные ниже функции:. Функция
вызова API система База производства ВОГ.. Функция
вызова BAPI системы SAP R/3.. Функция преобразования данных.
4.1.2. Требования к организации входных данных
Входные данные должны быть организованы в виде строк, содержащих логины и
пароли ответственного за интеграцию от систем SAP R/3 и База производства ВОГ.
4.1.3. Требования к организации выходных данных
Выходные данные должны быть организованны в виде строк в консоли,
сообщающих об успешном выполнении этапа передачи данных.
4.1.4. Требования к временным характеристикам
Программа должна выполнять один цикл передачи данных не более чем за 5
минут.
4.2. Требования к надежности
.2.1. Требования к обеспечению надежного (устойчивого)
функционирования программы
Надежное (устойчивое) функционирование программы
должно быть обеспечено выполнением
совокупности организационно-технических мероприятий, перечень которых приведен
ниже:
1. Организацией бесперебойного питания
технических средств.
2. Регулярным выполнением требований ГОСТ
51188-98. Защита информации.
. Испытания программных средств на наличие компьютерных вирусов.
. Регулярной проверкой целостности информационной базы и
восстановления ее в случае необходимости.
4.2.2. Время восстановления после отказа
Время восстановления после отказа, вызванного сбоем электропитания
технических средств (иными внешними факторами), не фатальным сбоем операционной
системы, не должно превышать времени, необходимого на перезагрузку операционной
системы и запуск программы, при условии соблюдения условий эксплуатации
технических и программных средств.
Время восстановления после отказа, вызванного неисправностью технических
средств, фатальным сбоем (крахом) операционной системы, не должно превышать
времени, требуемого на устранение неисправностей технических средств и
переустановки программных средств.
4.2.3. Отказы из-за некорректных действий оператора
Отказы программы вследствие некорректных действий пользователя исключены.
4.3. Условия эксплуатации
.3.1. Климатические условия эксплуатации
Климатические условия эксплуатации, при которых должны обеспечиваться
заданные характеристики, должны удовлетворять требованиям, предъявляемым к
техническим средствам в части условий их эксплуатации.
4.3.2. Требования к видам обслуживания
См. Требования к обеспечению надежного (устойчивого) функционирования программы.
4.3.3. Требования к численности и квалификации персонала
Минимальное количество персонала, требуемого для работы программы - 2
штатные единицы - ответственный за интеграцию и системный администратор.
Системный администратор должен иметь высшее профильное образование.
Ответственный за интеграцию должен быть знаком с процессом интеграции,
знать возможные причины отказа модуля интеграции и способы устранения его
неисправностей.
4.4. Требования к составу и параметрам технических средств
В состав технических средств должен входить IBM-совместимая серверная машина с характеристиками не
хуже стандартных персональных компьютеров Заказчика, на которых ведется
разработка.
4.5. Требования к информационной и программной
совместимости
.5.1. Требования к информационным структурам и методам
решения
Требования к информационным структурам на входе и выходе, а также к
методам решения не предъявляются.
4.5.2. Требования к исходным кодам и языкам программирования
Исходные коды программы должны быть реализованы на языке C#. В качестве
интегрированной среды разработки программы должна быть использована среда Microsoft Visual Studio 2015.
4.5.3. Требования к программным средствам, используемым
программой
Системные программные средства, используемые программой, должны быть
представлены лицензионной локализованной версией операционной системы Windows 7.
4.5.4. Требования к защите информации и программ
Защита модуля должна обеспечиваться комплексом программно-технических
средств и поддерживающих их организационных мер.
Защита модуля должна обеспечиваться на всех технологических этапах
обработки информации и во всех режимах функционирования, в том числе при
проведении ремонтных и регламентных работ.
Программно-технические средства защиты не должны существенно ухудшать
основные функциональные характеристики модуля.
4.6. Требования к маркировке и упаковке
Требования к маркировке и упаковке не предъявляются.
4.7. Требования к транспортированию и хранению
Требования к транспортированию и хранению не предъявляются.
4.8. Специальные требования
Специальные требования не предъявляются.
5. Требования к программной документации
.1. Предварительный состав программной документации
Состав программной документации должен включать в себя:
. Техническое задание.
. Программу и методики испытаний.
. Руководство системного администратора.
. Акт о выполнении работ.
6. Технико-экономические показатели
Ориентировочная экономическая эффективность не рассчитывается.
Предполагаемое число использований программы в год - 365 сеансов.
7. Стадии и этапы разработки
.1. Стадии разработки
Разработка должна быть проведена в шесть стадий:
. Разработка технического задания.
. Проектирование интеграционного решения.
. Разработка интеграционного модуля.
. Внедрение интеграционного модуля.
7.2. Этапы разработки
На стадии разработки технического задания должен быть выполнен этап
разработки, согласования и утверждения настоящего технического задания.
На стадии проектирования интеграционного решения должны быть
проанализированы структуры поступающих и отправляемых данных, а также
смоделирован функционал интеграционного модуля.
На стадии разработки интеграционного модуля должен быть разработан
интеграционный модуль, выполняющий функции, описанные на этапе проектирования.
На стадии внедрения интеграционный модуль должен быть размещен на сервере
Заказчика.
8. Порядок контроля и приемки
.1. Виды испытаний
Приемо-сдаточные испытания буду проводится на объекте Заказчика после
выполнения всех параллельных работ не позднее 01.08.2017.