IT-шные заметки

воскресенье, 22 апреля 2012 г.

четверг, 19 апреля 2012 г.

Автоматизированное тестирование композитов в Oracle SOA Suite 11g

Рассмотрим автоматизированное тестирование (Unit- или модульное тестирование, подробнее здесь) на примере простейшего композита с BPEL-процессом, который вызывает другой HelloWorld-композит (руководство по созданию здесь).

Последовательность шагов:

Создадим композит (например TestingProject) с BPEL-процессом (например TestBPELProcess), который на входе принимает строку, вызывает HelloWorld-композит и возвращает ответ от вызываемого композита:
Создадим новый набор тестов (TestSuite):
Создадим первый тест (например Test1):
Откроется дизайнер теста:
Проинициализируем входную переменную:
Сгенерируем входную переменную нажав "Generate":
Теперь проинициализируем выходную переменную:
Добавить новое утверждение (Assert), выбрать тип "Assert Output", сгенерировать выходную переменную и изменить её значение:
Получился простейший тест - вводим входную и выходную переменную, если значения совпадут, то тест пройден успешно, если нет, то тест не пройден.
Теперь сделаем простейший тест с использованием эмуляции вызова сервиса (т.е. вместо реального вызова сервиса будет возвращаться определённое значение). Для этого создадим новый тест (например Test2):
Повторить шаги 5-8 для второго теста. Получится следующее:
Далее создадим эмуляцию для сервиса HelloWorldProcess. Для этого:
Перейти в закладку "Emulates" и создать эмуляцию:
Сгенерируем ответ сервиса:
Второй тест получился таким:
Развернём композит на сервере Oracle SOA Suite 11g.
Зайти в Oracle Enterprise Manager Fusion Middleware Control, выбрать наш композит и перейти в закладку "Unit Tests":
Выбрать тесты для запуска и нажать "Execute":
Ввести имя запуска теста:
После окончания выполнения тестов можно увидеть результат выполнения каждого теста:
А так же увидеть детали сравнения на основе которых определяются результаты теста:

среда, 18 апреля 2012 г.

Конфигурирование автоматической миграции сервера

Описание: Описана настройка автоматической миграции серверов в конфигуции с двумя физическими машинами.
ПО: RHEL 5.5, Weblogic 10.3.5.

Есть простой Weblogic-домен следующей конфигурации:
Weblogic сервера:

AdminServer - порт 7001;
mserver1 - порт 7100.

Есть две физические машины (с точки зрения ОС) с IP-адресами, например:

192.168.2.130
192.168.2.96

Последовательность шагов:

Необходимо разрешить пользователю операционной системы под которым развернут Oracle FMW (в нашем случае - это weblogic) полномочия для запуска команд /sbin/ifconfig и /sbin/arping. Для этого пользователем root добавим в файл /etc/sudoers следующую строку (выделена красным):

 ......
 ## Next comes the main part: which users can run what software on  
 ## which machines (the sudoers file can be shared between multiple  
 ## systems).  
 ## Syntax:  
 ##  
 ##   user  MACHINE=COMMANDS  
 ##  
 ## The COMMANDS section may have other options added to it.  
 ##  
 ## Allow root to run any commands anywhere  
 root  ALL=(ALL)    ALL  
 weblogic    ALL=NOPASSWD:  /sbin/ifconfig,/sbin/arping  

 ## Allows members of the 'sys' group to run networking, software,  
 ## service management apps and more.  
 ......

Для обеспечения работоспособности необходим дополнительный "плавающий"/виртуальный IP-адрес из той же подсети, например: 192.168.2.139. После этого выполнить следующие команды на первой машине:
```
 $ sudo /sbin/ifconfig eth0:1 192.168.2.139 netmask 255.255.252.0  
 $ sudo /sbin/arping -q -U -c 3 -I eth0 192.168.2.139  
```
Добавить в переменную PATH следующее (лучше на уровне профиля пользователя, если используется bash, то это файл ~/.bash_profile):
```
 PATH=$PATH:$MW_HOME/wlserver_10.3/common/nodemanager:$MW_HOME/user_projects/domains/bam_domain/bin/server_migration:$MW_HOME/wlserver_10.3/common/bin  
 export PATH
```
Зайти в mserver1 и ввести Server Listen Address - 192.168.2.139:
Клонируем mserver1 (переходим в "Environment"->"Servers", выбираем mserver1 и нажимаем на кнопку "Clone"). Новый сервер:
- Server Name - mserver2;
- Server Listen Address - 192.168.2.96;
- Server Listen Port - 7200.
Создаем кластер:
- Name - WLS_Cluster;
- Messaging Mode - Unicast.
Добавляем в данный кластер оба сервера - mserver1 и mserver2:
На каждой физической машине (с т.з. операционной системы) сконфигурируем по Node Manager-у (подробнее здесь) и создадим две Weblogic-машины (Machines):
- Machine1 - 192.168.2.130;
- Machine2 - 192.168.2.96.
Соотнесём Weblogic-сервера и Weblogic-машины следующий образом:
- mserver1 - Machine1;
- mserver2 - Machine2.
Создать новый Data Source для механизма контроля миграции (если потребуется, то создать отдельного пользователя в СУБД. Не использовать административных пользователей, таких как SYS и SYSTEM) и соотнесём его с кластером WLS_Cluster:
Создадим необходимую служебную таблицу для механизма контроля миграции, для этого надо выполнить скрипт лежащий в $MW_HOME/wlserver_10.3/server/db/<СУБД>/leasing.ddl.
Если используется технология JMS, то перейти в "Services"->"Persistence Stores" и проверить какие типы Persistence Store-ов используются:
- Если FileStore, то обеспечить доступ к директориям со второго сервера, как правило для этого используется раздел дискового массива или кластерной файловой системы.
- Если JDBCStore, то соотнести используемый Data Source с кластером WLS_Cluster.
Необходимо донастроить Node Manager-ы на каждой физической машине, добавить опции для сетевых интерфейсов в файл nodemanager.properties:
```
 Interface=eth0  
 NetMask=255.255.255.0  
 UseMACBroadcast=true  
```
где eth0 - имя сетевого интерфейса на котором будет поднят "плавающий"/виртульный IP-адрес.
Затем в Weblogic Console выбрать кластер WLS_Cluster и перейти в "Configuration"->"Migration" и заполнить поле "Data Source For Automatic Migration:", где выбрать созданный Data Source для механизма контроля миграции (см. пункт 11):
Далее перейти в "Environment"->"Servers" выбрать mserver1. Перейти в "Configuration"->"Migration" и поставить галку "Automatic Server Migration Enabled". Аналогично для mserver1:
Перезапустить сервера и протестировать миграцию.

среда, 11 апреля 2012 г.

Ошибка "BEA-149259 Server ... in cluster ... is being brought up in administration state due to failed deployments" и вариант её решения

Ошибка:
В Weblogic-кластере сервер (в моём случае soa_server) стартует в статус ADMIN, а в логе серверы фигурирует ошибка:

...
<Emergency> <Deployer> <BEA-149259> <Server 'soa_server' in cluster 'SOA_Cluster' is being brought up in administration state due to failed deployments.>   
...

Причина:
Особенность состояния ADMIN в Weblogic-сервере: ошибки возникающие в состоянии PREPARE заставляют сервер оставаться в фазе ADMIN.

Вариант решения:
Исправить ошибки в состоянии PREPARE (лучший вариант) или запускать сервер с ключом:

-Dweblogic.deployment.IgnorePrepareStateFailures=true

четверг, 5 апреля 2012 г.

Поиск Java-класса в директории

Для поиска java-класса по всем jar в директории и поддиректориях можно воспользоваться утилитой JarScan (автор Geoff Yaworski). Загрузить её можно с сайта автора или отсюда.

Пример использования:

 $ java -jar jarscan.jar -dir /opt -class weblogic.jdbc.sqlserver.SQLServerDriver

где /opt - директория для поиска;
weblogic.jdbc.sqlserver.SQLServerDriver - имя класса.

воскресенье, 22 апреля 2012 г.

Рекомендации по настройке JVM для Weblogic Server в промышленном окружении

четверг, 19 апреля 2012 г.