Шина данных ibm integration bus

Содержание
  1. IBM Integration Bus FAQ for Databases
  2. Question & Answer
  3. Question
  4. Answer
  5. 1. What database versions are supported by IIB?
  6. 5. How do I configure IIB for global co-ordination (XA) for my database?
  7. 6. Is there a way to configure connection pooling for database connections made by IIB?
  8. 7. Where can I download database drivers? Can I download drivers from DataDirect and use them?
  9. 12. Are there any database configuration additional steps required for IIB migration?
  10. 13. What database credential did I configure for database access?
  11. 14. How can I view JDBC provider configurable service properties?
  12. 15. Is there a way to validate ODBC configuration?
  13. 16. Does IIB report database SQL exceptions if an error occurs?
  14. 17. Is there a database connection idle time? Can this be tuned?
  15. 18. Is IE02 SupportPac required for IIB to communicate with the databases?
  16. 19. How do I capture ODBC / JDBC traces in IIB?
  17. 20. Are there any additional references that may help me with IIB connectivity with the application databases?
  18. Product Synonym
  19. Document Information
  20. Содержание
  21. Основные функции ESB
  22. Архитектура ESB
  23. Достоинства и недостатки
  24. Разработка Enterprise Service Bus
  25. Шлюз служб
  26. Шина сообщений
  27. Подходы к интеграции приложений Enterprise Service Bus
  28. Введение
  29. Интеграция по типу «точка­точка»
  30. Единая сервисная шина
  31. Управление бизнес-процессами
  32. Предложения на рынке
  33. Заключение
  34. Установка и базовая настройка IBM Integration Bus V9

IBM Integration Bus FAQ for Databases

Question & Answer

Question

The following is a list of answers to frequently asked questions (FAQ) about Database in IBM Integration Bus (IIB) for new and experienced users.

Answer

1. What database versions are supported by IIB?

The following page lists the complete system requirements for IIB


    Select the IIB version and the Operating System to see specific requirements.

The Prerequisites tab provides information on the database version support

The JDBC drivers supported by IIB can be found here.


    Select the IIB version and the Operating System to see specific requirements.

The Prerequisites tab provides information on the JDBC driver versions supported

IIB provides DataDirect wire protocol drivers for ODBC connectivity for all supported databases except DB2 and Informix. For DB2 and Informix, database client is required to be installed on the IIB machine. For all the other supported databases, IIB does not require a database client installation on the IIB machine to connect to remote database.

IIB supports ODBC and JDBC connectivity with database. The following pages provide detailed steps required for configuring IIB connectivity with application databases using ODBC and JDBC.

5. How do I configure IIB for global co-ordination (XA) for my database?

6. Is there a way to configure connection pooling for database connections made by IIB?

Connection pooling for JDBC connections to databases can be configured in the JDBC configurable service using parameter ‘maxConnectionPoolSize’
ODBC connections to databases are managed internally by each IIB Int.Server, and therefore no configurable connection pooling options are provided.

7. Where can I download database drivers? Can I download drivers from DataDirect and use them?

Database drivers downloaded directly from DataDirect or other sources are not supported with IIB.

JDBC drivers are provided by the respective databases.

You can use a graphical map in IIB message flows to update/modify application databases using JDBC. It involves creating/using database definition files in the IIB Toolkit and using them to select or update the databases. The following links describe using the maps in IIB flows to update/modify the databases:

When a database call is made from within a message flow node, the flow constructs the appropriate SQL, which is sent using ODBC to the database manager. As part of this process, the SQL statement is prepared using the SQLPrepare function, and a statement handle is acquired so that the SQL statement can be executed.

For performance reasons, after the statement is prepared, the statement and handle are saved in a cache to reduce the number of calls to the SQLPrepare function. If the statement is already in the cache, the statement handle is returned so that it can be re-executed with newly bound parameters. The statement string is used to perform the cache look up. By using hardcoded SQL strings that differ slightly for each message, the statement is not found in the cache, and an SQLPrepare function is always performed (and a new ODBC cursor is opened).

When using PASSTHRU statements, use parameter markers so that the same SQL prepared statement can be used for each message processed, with the parameters being bound at run time. This approach is more efficient in terms of database resources and, for statements that are executed repeatedly, it is faster. However, it is not always possible to use parameter markers, or you might want to dynamically build the SQL statement strings at run time. This situation potentially leads to many unique SQL statements being cached. The cache itself does not grow that large, because these statements themselves are generally not big, but many small memory allocations can lead to memory fragmentation.

If you encounter these types of situations, disable the caching of prepared statements by setting the MQSI_EMPTY_DB_CACHE environment variable in the IIB start up environment to an arbitrary value. When this environment variable is set, the prepared statements are emptied at the end of processing for each message. This might cause a slight performance degradation because every SQL statement is prepared.

12. Are there any database configuration additional steps required for IIB migration?



From WebSphere Message Broker V7 onwards there is no database pre-requisite. IBM Integration Bus does not require a database for any internal function.

13. What database credential did I configure for database access?

The username(s) configured to access a datasource can be found in the following file:


    /registry/ /CurrentVersion/ directory or directory with odbc or jdbc prefix>/UserId.dat

The password is in file Password.dat in the same directory, however it is encrypted so it is not possible to find out what password you configured.

14. How can I view JDBC provider configurable service properties?

The following command display’s all configured JDBC provider properties:

15. Is there a way to validate ODBC configuration?

IIB provides a command mqsicvp which can be used to test and validate ODBC configuration.

Following is the command usage:

16. Does IIB report database SQL exceptions if an error occurs?

Yes. IIB reports database exceptions in the log when encountering database related errors, unless the message flow is designed to handle them. These messages are generated by IIB and will show the database SQL exceptions.

Читайте также:  Что такое ком в раздатке на егерь

IIB reports SQL exceptions in messages BIP2322E and BIP2393E. These error messages include inserts which show the SQL exception received from database during processing. The database error insert helps identify the reason for the error.

17. Is there a database connection idle time? Can this be tuned?

18. Is IE02 SupportPac required for IIB to communicate with the databases?

IE02 is installed as a part of the IIB V9 and V10 installations.

From WMB V8 onwards, IE02 is required for an Execution Group (IIB Int.Server) to establish ODBC connectivity with all the supported databases. IE02 is installed when WMB V8 (or IIB) is installed.

For WMB V7, the SupportPac IE02 is required only for ODBC connectivity with Solid DB.
In WMB V7, IE02 has to be downloaded from the SupportPac link:http://www.ibm.com/support/docview.wss?uid=swg27007197#2

19. How do I capture ODBC / JDBC traces in IIB?

For JDBC trace instructions, please contact the appropriate database provider.

20. Are there any additional references that may help me with IIB connectivity with the application databases?

The following WSTE presentation gives the list of top ten known questions/problems
http://www.ibm.com/support/docview.wss?uid=swg27036313

Product Synonym

WMB MB WebSphere Message Broker IBM Integration Bus IIB IBMIB MQ Integrator WBIMB WBI-MB MQSI WMQI

Document Information

Modified date:
23 March 2020

Источник

ESB (Enterprise Service Bus) — дословно можно перевести как «сервисная шина предприятия». ESB описывает вполне реальный программный продукт, в задачи которого входит упрощение вызова службы за счет управления всеми взаимодействиями на пути от потребителя службы к поставщику и обратно. Двумя наиболее часто упоминаемыми возможностями ESB являются преобразование сообщений и их маршрутизация. На шину ESB в архитектуре SOA возложена важнейшая задача обеспечения взаимодействия систем из слабосвязанных сервисов в сети. Аналитики Gartner определяют ESB как новый тип программного обеспечения промежуточного уровня, который объединяет функциональные возможности других уже существующих типов промежуточного обеспечения. Корпоративная сервисная шина поддерживает Web-сервисы, реализуя протокол SOAP (Simple Object Access Protocol, Простой протокол доступа к объектам) и используя язык WSDL (Web Services Description Language, Язык описания Web-сервисов) и спецификацию UDDI (Universal Description, Discovery and Integration, Универсальное описание, обнаружение и интеграция).

Содержание

300px ESB

300px ESB1

Основные функции ESB

Архитектура ESB

Основа архитектуры ESB — это идея использования общей интеграционной инфраструктуры всеми корпоративными приложениями на базе обмена сообщениями. Все приложения взаимодействуют через одну точку, которая, в случае необходимости, обеспечивает сохранность обращений, преобразование данных и транзакции. При этом целью интеграции приложения является создание единственного модуля (или адаптера), который отвечает за «подключение» приложения к ESB. Последующую обработку сообщений и их маршрутизацию в другие системы, ESB выполняет на основании установленных бизнес-правил самостоятельно. Этот подход обеспечивает превосходную гибкость, простоту масштабирования и переноса, поэтому в случае замены одного из приложений подключенного к шине, перенастраивать остальные не нужно.

Достоинства и недостатки

Достоинствами ESB является:

К числу недостатков ESB относят:

Разработка Enterprise Service Bus

Отличительной чертой Web-служб является то, что потребитель имеет возможность динамически связываться с провайдером службы. Все это происходит благодаря двум главным функциональным возможностям:

Самоописание Web-служб облегчило интеграцию с помощью объявления интерфейсов, которым нужно было следовать. Благодаря динамическому обнаружению службы, потребитель был освобожден от зависимости от конкретного провайдера с определенным адресом, однако, и эта возможность создала свои собственные проблемы. Достаточно тяжело было решить вопрос связи потребителя с провайдером раз и навсегда во время компиляции и потенциальным поиском нового провайдера при каждом вызове во время исполнения. Тогда ESB предложила другой вариант — дать возможность потребителю один раз динамически связаться с прокси-службой, имея при этом возможность использовать нескольких провайдеров и провайдеров, которые могут появиться в будущем, через эту прокси-службу. Все это говорит о том, что ESB делает службы доступными для их вызова потребителями и дает возможность потребителям найти службы программным способом.

Шлюз служб

Так называемый шлюз служб является краеугольным камнем синхронной ESB. Он выступает посредником между провайдерами и потребителями служб, оказывая при этом содействие в обработке синхронных вызовов с использованием брокера. Данный шлюз открывает доступ ко всем известным службам и прокси-службам каждой из них, поэтому он является своего рода «единым окном» для потребителя, желающего вызывать любую службу у любого провайдера, который известен шлюзу. Когда Web-службы координирует шлюз, они обладают способностью к самоописанию. Каждая служба предоставляет свой интерфейс с помощью WSDL, который состоит из следующих четырех частей:

Web-службы шлюза, а точнее их прокси-службы являются также обнаруживаемыми. Шлюз дает такую возможность в виде UDDI-службы. Чтобы найти адрес вызова службы потребитель подает запрос в UDDI-службу шлюза список провайдеров необходимой WSDL-операции и получает обратно адрес прокси-службы шлюза для этой операции.

Шина сообщений

Шаблон Message Bus (Шина сообщений) является основой асинхронной ESB. Шина сообщений — это набор каналов сообщений, которые настроены как пары каналов запрос-ответ. Каждая пара представляет службу, которую может вызвать потребитель, использующий шину. Потребитель посылает сообщение в очередь запросов службы и после этого выслушивает очередь ответов для получения результата. О том, кто предоставляет службу потребитель на самом деле не знает. Провайдеры служб также подсоединены к шине сообщений и прослушивают ее на наличие сообщений запросов. При наличии нескольких провайдеров службы, между ними происходит соревнование как между потребителями за получение конкретного запроса. Система сообщений, выполняемая шиной сообщений, функционирует как диспетчер сообщений и рассылает запросы провайдерам служб, оптимизируя эту рассылку в зависимости от степени нагрузки, сетевых задержек и т. д. После того как провайдер получил запрос, он выполняет службу и вносит результат в сообщение в очередь ответов, то есть провайдер и потребитель никогда не знают о месторасположении друг друга. Эта шина сообщений и является сущностью ESB.

Источник

Подходы к интеграции приложений Enterprise Service Bus

Введение

Интеграция приложений — вопрос, который рано или поздно встает перед ИТ-подразделением любой организации, в которой этих приложений больше одного. Вот далеко не полный перечень задач, укладывающихся в понятие «интеграция»:

Если выполнение подобного рода действий происходит на предприятии редко (например, раз в день), то организовать эти действия можно кустарным путем — например с помощью ручной выгрузки данных из одного приложения в формате Excel и загрузки их в другое приложение или вообще с помощью дублированного ввода информации сразу в две системы. Однако если потребность в информационном взаимодействии приложений возникает много раз в день, то встает вопрос о неэффективном использовании человеческих ресурсов и, как следствие, возникает необходимость автоматизации этой процедуры.

Интеграция по типу «точка­точка»

Задача интеграции «точка­точка» относительно проста. Нужно понять, каким образом каждая из двух взаимодействующих систем готова передавать и получать данные, создать соответствующие технические решения для обращения к этим интерфейсам, а также реализовать механизм преобразования данных из формата системы­источника в формат системы­приемника. В лучшем случае информационные системы предоставляют для интеграции специальный программный интерфейс (API), а в худшем — чтение и запись информации приходится производить непосредственно в базу данных приложения. В результате возникает локальное интеграционное решение — некий обособленный программный модуль собственной разработки со всеми вытекающими требованиями к его обслуживанию и поддержанию актуальности.

Читайте также:  Шаровая болтается в рычаге ниссан

1

Это не составляет большую проблему до тех пор, пока интеграций «точка­точка» мало — одна-две. Однако практика показывает, что количество интеграций «точка­точка» имеет склонность возрастать, а качество управления этими интеграциями — наоборот, стремительно падать. Причин тому много: возрастает число модулей интеграции, из организации уходят разработчики, делавшие тот или иной модуль, изменяются форматы данных в интегрируемых системах и т.д. Печальным итогом эволюционного развития интеграций «точка­точка» является сложнейший «фарш» интеграционных взаимодействий между приложениями предприятия, отношение к которому сотрудников ИТ-подразделения проще всего выразить в нескольких словах: «Пока работает — лучше не трогать». Однако такая ситуация не устраивает ни само ИТ-подразделение, ни бизнес-заказчиков.

2

Единая сервисная шина

Пережив несколько поколений различных подходов к интеграции приложений, мировая индустрия программного обеспечения пришла к концепции единой сервисной шины предприятия (Enterprise Service Bus, ESB). С точки зрения архитектуры, ESB — это программное решение, обеспечивающее взаимодействие всех интегрируемых приложений через единую точку, единообразно, предоставляя разработчикам и администраторам унифицированные и централизованные средства разработки, тестирования и контроля протекания всех интеграционных сценариев.

Основными компонентами, составляющими современную сервисную шину, являются:

Преимуществами использования единой сервисной шины можно назвать:

Еще одним важным требованием к функционалу ESB-среды является возможность реализации интеграции с внешними организациями — бизнес-партнерами, поставщиками, корпоративными клиентами, удаленными филиалами. Особенностями такой интеграции является непредсказуемое качество каналов, отсутствие гарантий доставки информации и слабая готовность к интеграции как таковой — как правило, организация-партнер предоставляет очень ограниченный спектр форматов обмена данными. На этот случай в составе интеграционной шины должно присутствовать средство построения B2B-взаимодействия, позволяющее осуществлять информационный обмен по открытым, в том числе отраслевым, стандартам, обеспечивать гарантированную доставку, обладать средствами настройки информационного обмена в разрезе конкретного бизнес-партнера и, конечно же, работать в полном соответствии с принципами самой интеграционной платформы, изолируя разработчика интеграционных сценариев от технических деталей взаимодействия с партнером.

3

Enterprise Service Bus

Управление бизнес-процессами

Существенная доля интеграционных сценариев подразумевает, что в информационный обмен вовлекаются не только приложения, выступающие в роли источников или приемников информации, но и люди — сотрудники организации, выполняющие различные задания или принимающие решения. В этом случае мы можем говорить о выходе за рамки «чистой» интеграции и появлении в фокусе нашего внимания новой сущности — бизнес-процессов, а в требованиях к интеграционной платформе — новой функциональности по управлению бизнес-процессами (Business Process Management, BPM). При наличии BPM-требований интеграционная платформа должна предоставить в распоряжение разработчика:

На данный момент многие производители ПО склонны объединять BPM-среду и интеграционную шину в единую платформу промежуточного ПО, убирая существовавшее несколько лет строгое разделение между BPM-системами и средствами для интеграции приложений. Такой подход очень прогрессивен. Некоторые вендоры идут еще дальше и присоединяют к платформе профессиональные средства для моделирования бизнес-процессов. Пионером в этом является компания Software AG, предлагающая решение, объединяющее в себе известное средство моделирования ARIS Platform и интеграционную/BPM среду webMethods.

4

Комплексное использование интеграционной платформы

Предложения на рынке

На текущий момент можно выделить три группы предложений ПО для построения ESB. Эти группы разнятся как по цене, так и по предлагаемой функциональности.

Первая группа — предложения от фирм, чьи продукты лидируют в исследованиях аналитических агентств по всем обозначенным в статье категориям (ESB, SOA Governance, BPM, B2B). В эту группу входят:

В принципе, тем, кто не любит компромиссы, можно выбирать любого из этих производителей — все перечисленные компании предлагают полноценные линейки продуктов (правда, в случае с Oracle не всегда понятно, о каком именно продукте идет речь, поскольку после покупки ряда компаний Oracle предлагает сразу несколько продуктов, не всегда в достаточной степени интегрированных между собой). Немного особняком стоит Tibco, так как размер этой компании гораздо меньше размера остальных участников данной четверки, что может вызвать некоторые сомнения в ее стабильности. Software AG — пока не очень известный на российском рынке производитель, но у платформы webMethods, которая является сегодня ключевым предложением этой компании, большой потенциал. IBM и ее продукты знают и используют уже очень многие предприятия, но у некоторых из них возникают претензии по стоимости самого внедрения и обслуживания системы.

Вторая группа предложений — это компании, сконцентрированные в основном на «чис­том» ESB-функционале и достигшие здесь успеха. В эту группу попадают: Sun (Glassfish), Progress (Sonic) и Fujitsu.

Предложения от этих компаний хороши, если вы не собираетесь расширять сферу применения своей платформы в сторону BPM и/или B2B. В противном случае вы рискуете оказаться наедине с недостаточно проработанной функциональностью и существенно увеличить свои расходы на ее доработку до соответствия своим потребностям.

Третья группа наиболее многочисленна и включает все предложения, не вошедшие в предыдущие две группы. Перечисление всех предложений на тему ESB в данной статье бессмысленно, вы можете получить такой список в любом поисковике. Если ваш бюджет на интеграцию ограничен, а сами вы склонны к экспериментам — вы вполне можете попытать счастья с любым из них. Однако риски, касающиеся как недостаточно проработанной функциональности, так и возможных проблем с надежностью, технической поддержки и перспектив развития продуктов, вы принимаете на себя.

Заключение

В заключение хотелось бы дать читателям несколько простых советов по выбору интег­рационной шины:

Источник

Установка и базовая настройка IBM Integration Bus V9

В этой статье мы подробно рассмотрим процесс установки и базовой настройки IBM Integration Bus V9.0.0.2 на ОС Red Hat Enterprise Linux.

Базовая настройка будет включать:

Установка IIB V9

Для установки IIB V9.0.0.2 нам потребуются дистрибутив IIB V9.0.0.0 и fix pack 9.0.0.2. Fix pack для IIB – это, по сути, самостоятельный дистрибутив IIB, включающий все необходимое и не требующий предварительной установки базовой версии 9.0.0.0. Однако, из дистрибутива базовой версии нам будут нужны файлы лицензии, но об этом позже.

Все действия производим из-под пользователя root. Сначала создаем группу mqbrkrs и пользователя mqm из-под которого будет работать IIB:

Создаем директорию для размещения дистрибутивов, например:

Копируем в эту директорию дистрибутив IIB V9.0.0.0 и распаковываем его:

Создаем директорию для размещения дистрибутива fix pack 9.0.0.2, копируем его и распаковываем:

Копируем лицензию из дистрибутива базовой версии 9.0.0.0 в дистрибутив FP02:

Запускаем инсталлятор IIB V9.0.0.2 в консольном режиме и следуем его шагам:

После успешной установки IIB, запускаем инсталлятор IBM Integration Bus ODBC Database Extender в консольном режиме и следуем его шагам:

Читайте также:  Сколько стоит гидротрансформатор акпп на ауди а6

Если при установке появилась ошибка:

То необходимо установить недостающий пакет:

yum install glibc.i686

Если при запуске инсталлятора появилась ошибка:

То необходимо установить:

yum install libgcc.x86_64
yum install libgcc.i686

Опционально устанавливаем IBExplorer:

При запуске IBExplorer может возникнуть ошибка с libgcc_s.so.1, тогда выполняем команду:

После установки всех компонент изменяем владельца и группу на установленных файлах:

Из под пользователя mqm, “закрепляем” профайл IIB:

Профайл, т.е. запуск mqsiprofile, определяет настройки среды исполнения IIB.

P.S.: Для удаления IIB и его компонентов запустите uninstaller:

На этом установка IIB V.9.0.0.2 завершена. Мы установили среду исполнения IIB, инструмент управления, имеющий графический интерфейс – IBExplorer и ODBC Database Extender для подключения к БД. Теперь перейдем к настройке IIB.

Базовая настройка IBM Integration Bus

1. Создание узла интеграции

Необходимым условием для создания узла интеграции версии 9.0.0.2 является наличие менеджера очередей WebSphere MQ. Создадим узел интеграции MYIIB9:

В нашем примере будет создан узел интеграции MYIIB9 с параметрами:

-q queueManagerName

Имя менеджера очередей. Обязательный параметр. Необходим для связывания создаваемого узла интеграции с существующем менеджером очередей.

-g configurationChangeTimeout

Максимальное время (в секундах, от 10 до 3600), отведенное на выполнение запроса пользователя для изменения конфигурации узла интеграции. Опциональный параметр. Значение по умолчанию: 300 секунд.

-k internalConfigurationTimeout

Максимальное время (в секундах, от 10 до 3600), отведенное на выполнение внутреннего запроса по изменению конфигурации сервера интеграции. Например, это время за которое узел интеграции должен успеть запустить сервер интеграции после получения соответствующей команды. Опциональный параметр. Значение по умолчанию: 60 секунд. Относится ко всем серверам интеграции узла.

Статус административной защиты узла интеграции. Возможные значения: active/inactive. Опциональный параметр.

Подробную информацию о создании узла интеграции с помощью команды можно получить в соответствующем разделе IBM Integration Bus Knowledge Center.

Изменяем функциональный уровень IIB

Активация новых возможностей fix pack 9.0.0.2:

2. Создание сервера интеграции

Для создания сервера интеграции следует воспользоваться командой mqsicreateexecutiongroup:

Хорошая практика в названии сервера интеграции использовать номер внутреннего http порта, который будет присвоен этому серверу. Для того, что бы вывести список всех серверов интеграции узла и их соответствующие состояния, необходимо воспользоваться командой mqsilist:

3. Настройка параметров сервера интеграции

Переключение HTTPInput и HTTPReply nodes с листнера узла интеграции на встроенные листнеры серверов интеграции (Switching from a broker-wide listener to embedded listeners):

Устанавливаем http-порт для сервера интеграции:

Изменяем размер хипа JVM сервера интеграции (min 256 Mb/max 512 Mb):

После выполненных настроек требуется перезапустить сервер интеграции.

4. Вывод системного лога узла интеграции в отдельный файл

Системный лог узла интеграции, Administration Log, по умолчанию формируется в /var/log/messages.
Для того, что бы вывести системный лог узла интеграции в отдельный файл необходимо отредактировать /etc/rsyslog.conf.

В секции #### RULES #### добавить user.none:

Таким образом мы настроим вывод всех записей содержащих слово “IBM” в журнал /var/log/mqsi/.system/broker.myiib9.log.

Теперь настроим ротацию лога по размеру 20 Мб. Для этого в /etc/logrotate.d создаем файл iib со следующим содержанием:

Создаем пустой лог файл IIB и изменяем его владельца:

После всех настроек необходимо перезапустить rsyslog командой:

service rsyslog restart

Теперь в директории /var/log/mqsi/.system/ будет формироваться системный лог узла интеграции broker.myiib9.log, с ротацией и архивацией журнала по достижении 20 Мб, а так же глубиной хранения 10 архивных файлов.

5. Настройка ODBC подключения к БД Oracle

IBM Integration Bus ODBC Database Extender по умолчанию устанавливается в директорию /opt/ibm/IE02/2.0.1

После его установки необходимо перезапустить Integration Bus:

mqsistop MYIIB9
mqsistart MYIIB9

Затем перейти в каталог:

И скопировать файлы odbc.ini и odbcinst.ini в каталог /var/mqsi/odbc.

Установить права на файлы:

Затем отредактировать bash_profile пользователя mqm, который расположен в директории /var/mqm. В конец файла .bash_profile (или .bashrc) добавляем строки (перед строкой “. /opt/ibm/mqsi/9.0.0.2/bin/mqsiprofile“):

После чего перезапускаем систему, выполнив команду reboot.

После перезагрузки системы редактируем файл /var/mqsi/odbc/odbc.ini. Находим описание подключения к БД Oracle, раздел ORACLEDB:

Копируем или редактируем этот раздел для создания нового источника данных, например:

В самом низу файла, в секции “Mandatory information stanza” прописываем путь к драйверам в параметре InstallDir:

Сохраняем и закрываем файл.

Для многопоточного доступа к БД в файле odbcinst.ini следует добавить параметр Threading=2.

Командой mqsisetdbparms устанавливаем имя пользователя и пароль для подключения к базе:

После этого необходимо перезапустить сервер интеграции, иначе в логах могут быть ошибки:

Проверить соединение c БД можно с помощью команды mqsicvp. Для проверки всех DataSources узла интеграции:

mqsicvp MYIIB9

Для конкретного источника данных, например TEST.DS:

Настройка подключения к базе данных завершена.

6. Настройка доступа в IIB Web User Interface: role-based security

Ранее мы создали узел интеграции MYIIB9 с выключенной административной защитой. Это означает, что любой пользователь используя веб-браузер может зайти в административный интерфейс узла интеграции (Web User Interface) и выполнять любые действия по изменению конфигурации.

Допустим, нам необходимо ограничить доступ к веб-интерфейсу администрирования IIB для всех пользователей, кроме администраторов.

Для этого в системе создадим специального пользователя-администратора для WebUI, назовем его, например, webadmin:

Затем создадим этого пользователя в IIB (-r – роль/пользователь в системе, -a – пароль):

Останавливаем узел интеграции:

Запускаем узел интеграции:

Теперь доступ в WebUI защищен, а при попытке входа будет отображаться форма для ввода логина/пароля:WebUI

Подробнее о настройке доступа в WebUI можно ознакомиться в статье на DeveloperWorks:

На этом мы закончим рассматривать вопросы установки и базовой настройки продукта IBM Integration Bus V9.

3 комментария на “ Установка и базовая настройка IBM Integration Bus V9 ”

После прописывания пароля для датасорса, надо рестартать только ту/те eg которые его используют, весь брокер можно не грузить.

Так же не понял зачем всю железку грузить simple smile

Спасибо за добрые слова и комментарий!
В статье изменение параметров сервера интеграции дано для ознакомления, в качестве примера, и не является рекомендацией по тюнингу.

Значение ‘-1′ параметров jvmMinHeapSize и jvmMaxHeapSize, означает, что будет использоваться heap size по умолчанию, который равен 32 MB и 256 MB соответственно.
При активной работе у EG часто растет потребление памяти, но это не обязательно связано с утечками памяти и размером JVM, а вызвано конструктивными особенностями продукта.
Подробности тут:
http://www-01.ibm.com/support/docview.wss?uid=swg21106136

Причин для увеличения размера хипа может быть несколько. Например, рекомендуется увеличить хип при увеличении во флоу числа Node, написанных на java. При увеличении числа http тредов так же рекомендуется увеличить хип.

По поводу “После прописывания пароля для датасорса, надо рестартать только ту/те eg которые его используют, весь брокер можно не грузить.” – в статье не написано, что нужно перезапускать весь брокер.
Указано, что нужно перезапустить именно сервер интеграции (EG), а не узел инетграции (broker), цитата:
“После этого необходимо перезапустить сервер интеграции, иначе…”.

Источник

Оцените статью
Adblock
detector