Показаны сообщения с ярлыком fmw. Показать все сообщения
Показаны сообщения с ярлыком fmw. Показать все сообщения

среда, 30 декабря 2015 г.

Пользовательские задачи Oracle BPM 12c: роли и подразделения пользователей

Участником задачи могут быть:
  • пользователь (user);
  • группа пользователей (group);
  • роль пользователей (app.role), в контексте Oracle BPM.
Взаимосвязь между участниками указана ниже:

Орг.единицы (Organization Unit) определяют структуру организации, например:

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

Рассмотрим на примере как работает механизм орг.единиц:

В соответствии со схемой выше, в организации есть 3 бухгалтера по одному в каждом отделении и аналогично 3 инженера в каждом отделении.
Создадим две роли "Бухгалтер" и "Инженер" и три орг.подразделения и добавим в них соответствующих сотрудников. Таким образом получается:
Роль
Пользователь
Организационное подразделение
Бухгалтер
Иванова
Западносибирское отд.
Сидирова
Уральское отделение
Кузнецова
Дальневосточное отд.
Инженер
Петрова
Западносибирское отд.
Алексеева
Уральское отделение
Борисова
Дальневосточное отд.

Создадим простейший BPMN-процесс с одной задачей:

Но данная задача должна назначаться на роль "Бухгалтер" уральского подразделения, для этого добавляем перед назначением задачи добавим script-активность, в которой укажем необходимое орг.подразделение (Process / Predefined Variables / Organization Unit):
Если бы мы не указали орг.подразделение, то задача назначилась на всех участников роли "Бухгалтер", т.е. доступ был бы у 3-х сотредников. 
Так как мы указали орг.подразделение, то задача назначится на того сотрудника роли "Бухгалтер", который входит в указанное подразделение, т.е. Сидорову.

Данная функциональность позволяет сильно сократить количество ролей (без неё потребовалось бы 6 ролей вместо 2).

воскресенье, 8 ноября 2015 г.

Пользовательские задачи Oracle BPM 12c: пример реализации ограничения перечня пользователей для операции "Делегирование"

По умолчанию задачу в Oracle BPM можно переназначить или делегировать на любого пользователя, роль и группу. Но можно ограничить этот перечень создав класс в BPM-проекте (в терминах JDeveloper), который реализует интерфейс oracle.bpel.services.workflow.task.IRestrictedAssignmentCallback.

Рассмотрим пример в котором нужно ограничить перечень пользователей для операции "Делегирование" следующим образом:
  • Если исполнителем задачи является группа или роль, то делегировать можно только пользователям из состава этой группы или роли;
  • Если исполнителем задачи является пользователь, то делегировать нельзя (пустой перечень доступных для делегирования пользователей).
Пример кода:
 import java.util.ArrayList;  
 import java.util.Collections;  
 import java.util.List;  
 import java.util.Map;  
   
 import oracle.bpel.services.workflow.IWorkflowConstants;  
 import oracle.bpel.services.workflow.task.IRestrictedAssignees;  
 import oracle.bpel.services.workflow.task.IRestrictedAssignmentCallback;  
 import oracle.bpel.services.workflow.task.impl.RestrictedAssignees;  
 import oracle.bpel.services.workflow.task.impl.TaskAssignee;  
 import oracle.bpel.services.workflow.task.model.Task;  
   
 import oracle.tip.pc.services.common.ServiceFactory;  
 import oracle.tip.pc.services.identity.BPMAppRole;  
 import oracle.tip.pc.services.identity.BPMAuthorizationService;  
 import oracle.tip.pc.services.identity.BPMGroup;  
 import oracle.tip.pc.services.identity.BPMIdentityService;  
 import oracle.tip.pc.services.identity.BPMUser;  
   
 import oracle.bpel.services.workflow.task.model.IdentityType;  
   
 public class RestrictedAssignmentCallbackImpl implements IRestrictedAssignmentCallback {  
   
   public IRestrictedAssignees getPermittedAssignees(Task task, Map map, String currentUser, String identityContext,  
                            String operation) {  
     List assignees = new ArrayList();  
     if (operation.equals(IRestrictedAssignmentCallback.OperationType.REASSIGN.toString())) {  
       //TODO реализовать логику для операции "Переназначение"  
     } else if (operation.equals(IRestrictedAssignmentCallback.OperationType.DELEGATE.toString())) {  
       try {  
         BPMIdentityService idenService = getIdentityServiceInstance(identityContext);  
         List<IdentityType> assigneesList = task.getSystemAttributes().getAssignees();  
         for (IdentityType assignee : assigneesList) {  
           if (IWorkflowConstants.IDENTITY_TYPE_GROUP.equals(assignee.getType())) {  
             List<BPMUser> usersInGroup =  
               idenService.getParticipantsToGroup(assignee.getDisplayName(), true);  
             for (BPMUser user : usersInGroup) {  
               assignees.add(new TaskAssignee(user.getName(), IWorkflowConstants.IDENTITY_TYPE_USER));  
             }  
           } else if (IWorkflowConstants.IDENTITY_TYPE_APPLICATION_ROLE.equals(assignee.getType())) {  
             List<BPMUser> usersInGroup =  
               idenService.getParticipantsToAppRole(assignee.getDisplayName(),  
                                  task.getApplicationContext(), false);  
             for (BPMUser user : usersInGroup) {  
               assignees.add(new TaskAssignee(user.getName(), IWorkflowConstants.IDENTITY_TYPE_USER));  
             }  
           } else if (IWorkflowConstants.IDENTITY_TYPE_USER.equals(assignee.getType())) {  
             // Пустой список  
             return new RestrictedAssignees(new ArrayList(), true);  
           }  
         }  
   
       } catch (Exception ex) {  
         ex.printStackTrace();  
       }  
     }   
   
     if (!assignees.isEmpty()) {  
       return new RestrictedAssignees(assignees, true);  
     }  
   
     return null;  
   }  
   
   public List<IRestrictedAssignmentCallback.OperationType> getRestrictedOperations(Task task, Map map,  
                                            String currentUser,  
                                            String identityContext) {  
     return Collections.emptyList();  
   }  
   
   private BPMAuthorizationService getAuthorizationService(String realmName) {  
     return ServiceFactory.getAuthorizationServiceInstance(realmName);  
   }  
   
   private BPMIdentityService getIdentityServiceInstance(String realmName) {  
     return ServiceFactory.getIdentityServiceInstance(realmName);  
   }  
 }  
   

суббота, 7 ноября 2015 г.

Пользовательские задачи Oracle BPM 12c: Custom Escalation Java Function

Custom Escalation Java Function указывается в конфигурации задачи для указания по какой логике будет выполняться эскалация для пользователей и групп (для ролей не используется!).

Custom Escalation Java Function рассмотрим на примере:
 package oracle.bpel.services.workflow.assignment.dynamic;  
   
 import java.util.List;  
 import java.util.Map;  
   
 import oracle.bpel.services.workflow.task.model.Task;  
 import oracle.bpel.services.workflow.assignment.dynamic.DynamicAssignmentException;  
   
 import oracle.tip.pc.services.common.ServiceFactory;  
 import oracle.tip.pc.services.identity.BPMAuthorizationService;  
   
 import oracle.tip.pc.services.identity.BPMAppRole;  
 import oracle.tip.pc.services.identity.BPMAuthorizationService;  
 import oracle.tip.pc.services.identity.BPMGroup;  
 import oracle.tip.pc.services.identity.BPMIdentityService;  
 import oracle.tip.pc.services.identity.BPMUser;  
 /*  
  * Обеспечивает эскалацию на владельца задачи.  
  */  
 public class OwnerEscalation implements IDynamicTaskEscalationFunction {  
   public String defaultUser;  
   
   @Override  
   public String getTaskEscalationUser(Task task) throws DynamicAssignmentException {  
     String ownerRole = task.getOwnerRole();  
     String ownerGroup = task.getOwnerGroup();  
     String ownerUser = task.getOwnerUser();  
     if (ownerRole != null) {  
       try {  
         BPMAuthorizationService idenService = ServiceFactory.getIdentityServiceInstance();  
         List<BPMUser> usersInRole =  
           idenService.getParticipantsToAppRole(ownerRole, task.getApplicationContext(), false);  
         if (usersInRole.size() > 0) {  
           // Берём первого пользователя  
           return usersInRole.get(0).getName();  
         }  
       } catch (Exception ex) {  
         ex.printStackTrace();  
       }  
     } else if (ownerGroup != null) {  
       try {  
         BPMAuthorizationService idenService = ServiceFactory.getIdentityServiceInstance();  
         List<BPMUser> usersInGroup = idenService.getParticipantsToGroup(ownerGroup, true);  
         if (usersInGroup.size() > 0) {  
           // Берём первого пользователя  
           return usersInGroup.get(0).getName();  
         }  
       } catch (Exception ex) {  
         ex.printStackTrace();  
       }  
     } else if (ownerUser != null) {  
       return ownerUser;  
     }  
     return defaultUser;  
   }  
   
   @Override  
   public String getTaskEscalationUser(String string) throws DynamicAssignmentException {  
     return defaultUser;  
   }  
   
   @Override  
   public void setInitParams(Map map) throws DynamicAssignmentException {  
     // Добавляем параметр указывающий на какого пользователя проводить эскалацию,   
     // если владелец задачи (Owner) не указан  
     defaultUser=(String)map.get("DEFAULT_USER");  
   }  
   
   @Override  
   public String getFunctionName() {  
     return "OWNER_ESCALATION";  
   }  
   
   @Override  
   public String getDescription() {  
     return "Escalation to task owner";  
   }  
 }  
   
Логика данного примера:
Если у задачи определён владелец (Owner), то эскалация будет выполняться на владельца. Иначе, на пользователя указанного в конфигурации как DEFAULT_USER

Важно:

  • Класс должен быть в пакете oracle.bpel.services.workflow.assignment.dynamic.

Установка:

  1. Собрать JAR содержащий класс и положить его в директорию $MW_HOME\soa\soa\modules\oracle.soa.ext_11.1.1
  2. Запустить ant в директории $MW_HOME\soa\soa\modules\oracle.soa.ext_11.1.1 (вероятно потребуется проинициализировать переменные окружения)
  3. Перезагрузить soa-сервер для того, чтобы новый класс был доступен серверу (был в classpath).
  4. Зарегистрировать Task Escalation Function:
    1. Войти в EM (Enterprise Manager Fusion Middleware Control)
    2. Перейти в soa-infra -> SOA Administration -> Workflow Properties
    3. Перейти на закладку Task и добавить наш класс (Add function) следующим образом:
Альтернативный вариант: вместо указанных действий в п.1-2 можно положить скомпилированный класс в директорию $MW_HOME\soa\soa\modules\oracle.soa.ext_11.1.1\classes

вторник, 3 ноября 2015 г.

Пользовательские задачи Oracle BPM 12c: новая функциональность таймеров

После авторизации в Oracle BPM Workspace 12c выбрав экземпляр любой задачи вы обнаружите, что у задач появились два новых действия:
  • Начать работу (Start Task)
  • Закончить работу (Stop Task)
Функциональность данных действий работает следующим образом:
После выполнения "Начать работу" включается таймер, а после выполнения "Закончить работу" таймер выключается и сохраняется длительность включённого таймера с нарастающим итогом

Особенности

  • Функциональность "Начать работу" / "Закончить работу" не генерируют событий (EDN), поэтому значения можно узнать через API или в следующем (по времени) генерируемом событии.
  • Если задача назначена на группу/роль, то выполнение "Начать работу" приводит так же к выполнению "Взять в работу".
  • Если пользователь выполнил "Начать работу" и затем исполнил/завершил задачу (т.е. не была выполнена операция "Закончить работу"), то значение таймера длительности будет 0. 
  • Таймер никак не связан с пользователями выполняющими действия. Последовательный пример: 
    1. назначается задача на первого пользователя
    2. первый пользователь выполняет "Начать работу"
    3. первый пользователь переназначает на второго пользователя
    4. второй пользователь выполняет "Закончить работу" и исполняет/завершает задача
    В итоге: нет информации сколько времени с задачей работал первый пользователь, а сколько второй. Есть только информация сколько времени прошло с включения таймера (действия "Начать работу") до выключения таймера (действия "Закончить работу").

Недостатки

  • Данная функциональность не документирована (ни в пользовательской документации, ни в Oracle Fusion Middleware Workflow Services Java API Reference for Oracle SOA Suite).
  • Следствие первого пункта - доступна только из Oracle BPM Workspace 12c (как следствие, не доступна, если вы не используете его).
  • Следствие первого пункта - данная функциональность может быть изменена вендором (пока не будет внесена в публичную документацию). 

суббота, 31 октября 2015 г.

Пользовательские задачи Oracle BPM 12c: эскалация

Под эскалацией в Oracle BPM 12c (и в 11g) подразумевается автоматическое переназначение исполнителя задачи на другую роль, группу или пользователя (обычно более высокого по иерархии).

Эскалация может производиться:
  • автоматически по истечению указанного времени в конфигурации задачи
  • пользователем выполнившим действие «Эскалировать» (Escalate), которое может быть доступно:
    • Исполнителю задачи (Assignee)
    • Владельцу задачи (Owner)
    • Администратору (Admin)

Особенности:

  • В зависимости от того на ком находится задача на момент эскалации:
    • Если это группа или пользователь, то отрабатывает указанная custom escalation java function (если функция не указана, то задача завершится будет ошибкой)
    • Если это роль, то выполняется эскалация на указанный в роли Escalation Path (может быть роль, группа, пользователь).
       
    • Последующие эскалации:
      • Если в Escalation Path указана роль, то последующая эскалация будет выполнятся на Escalation Path данной роли
      • Если в Escalation Path указан пользователь или группа, то отрабатывает указанная custom escalation java function (если функция не указана, то задача завершится будет ошибкой).
  • Для каждой задачи можно задать глубину автоматической эскалации, т.е. кол-во раз которое будет выполнятся эскалация. По истечению указанного количества задача становится просроченной (expired).

пятница, 29 июня 2012 г.

Удаление метаданных из MDS

Все команды выполняются из wlst.cmd или wlst.sh находящегося в SOA_HOME, у меня например это:
 C:\Apps\Oracle\Weblogic\10.3.6\Oracle_SOA1\common\bin\wlst.cmd  
  • Удаление файлов
    Примечание: удаляются файлы, но не каталоги:
    1. Соединяемся с SOA-сервером:
      wls:/offline> 
       connect('weblogic','welcome1','t3://bpm-dev.mycompany.com:8001')  
      
      где weblogic - логин административного пользователя;
      welcome1 - пароль административного пользователя;
      bpm-dev.mycompany.com - хост SOA-сервера;
      8001 - порт SOA-сервера.
    2. Выполняем удаление файлов:
      wls:/soa_dev/serverConfig>
       deleteMetadata('soa-infra','soa_server1','/apps/MyComponents/**')  
      
      где soa_server1 - имя SOA-сервера;
      /apps/MyComponents - директория из которой будут удаляться файлы;
      ** - удаление в текущем каталоги в всех вложенных каталогах.
  • Удаление каталогов (рекурсивное)
    Примечание: если в удаляемом каталоге нет ни одного файла может произойти ошибка и каталог не будет удалён.
    wls:/offline>
     sca_removeSharedData('http://bpm-dev.mycompany.com:8001', 
                          'MyComponents',
                          'weblogic',
                          'welcome1')  
    
    где bpm-dev.mycompany.com - хост SOA-сервера;
    8001 - http-порт SOA-сервера;
    MyComponents - директория из корневой директории apps которую следует удалить;
    weblogic - логин административного пользователя;
    welcome1 - пароль административного пользователя.

четверг, 15 марта 2012 г.

Клонирование Oracle Fusion Middleware 11g

Клонирование Oracle Fusion Middleware 11g (SOA Suite, ODI, IDM, Webcenter и т.д.) условно можно разделить на две логические части:
  • Клонирование Middleware Home;
  • Клонирование доменов.
Существует несколько ограничений по клонированию:
  • окружения должны быть идентичными, т.к. сервер назначения и сервер источник должны иметь одну и ту же операционную систему и разрядность (32 или 64);
  • система назначения и система источник должны иметь одного и того же административного пользователя (например, weblogic), но пароли могут быть различны. После завершения клонирования можно изменить пользователя.
Клонирование СУБД и других внешних систем, которые используются в приложениях/композитах выходят за рамки данной статьи.

Клонирование Middleware Home

Типовая структура Middleware Home (MW_HOME):
  1. Останавливаем все сервера (AdminServer и ManagedServer-а) всех доменов (на источнике), которые используют клонируемый Middleware Home;
  2. На источнике перейти в директорию:
     $ cd $MW_HOME/oracle_common/bin/  
  3. Затем выполнить команду:
     $ ./copyBinary.sh -javaHome /opt/jrockit-jdk1.6.0_26-R28.1.4-4.0.1/ 
    -archiveLoc /tmp/mw_copy.jar -sourceMWHomeLoc /opt/Middleware/
    где javaHome – директория c JDK;
          archiveLoc – имя файла для экспорта;
          sourceMWHomeLoc – директория в которой развернут MW_HOME.

  4. Скопировать файл экспорта с сервера источника на сервер назначения. А так же следующие файлы:
     $ ls $MW_HOME/oracle_common/bin/pasteBinary.sh  
     $ ls $MW_HOME/oracle_common/jlib/cloningclient.jar  
    

  5. Запускаем импорт Middleware Home на сервере назначения:
     $ ./pasteBinary.sh -javaHome /u01/jdk1.6.0_30/ 
    -archiveLoc mw_copy.jar -targetMWHomeLoc /u01/ofm  
    
    где javaHome – директория c JDK;
          archiveLoc – имя файла для импорта;
          targetMWHomeLoc – директория в которой будет развернут MW_HOME.

Клонирование доменов

  1. Проверяем, что все сервера домена (на источнике) для клонирования стартованы.
  2. Если в домене есть machine типа Unix Machine, то необходимо изменить её на тип Machine. Для этого необходимо:
     $ cp $DOMAIN_HOME/config/config.xml $DOMAIN_HOME/config/config.xml.bkp  
     $ vi $DOMAIN_HOME/config/config.xml  
    
    Далее найти следующую строку (или строки если несколько машин):
     <machine xsi:type="unix-machineType">  
    
    И заменить её (или их) на:
     <machine>  
    
    После этого перезапустить AdminServer.
  3. На сервере источнике перейти в директорию:
     $ cd $MW_HOME/oracle_common/bin/  
    
  4. Затем выполнить на источнике команду:
     $ ./copyConfig.sh -javaHome /opt/jrockit-jdk1.6.0_26-R28.1.4-4.0.1/  
                    -archiveLoc /tmp/soa_domain.jar 
                    -sourceDomainLoc /opt/user_projects/domains/soa_domain/     
                    -sourceMWHomeLoc /opt/Middleware/                         
                    -domainHostName oracle-sb.tsretail.ru    
                    -domainPortNum 9000 
                    -domainAdminUserName weblogic 
                    -domainAdminPassword /tmp/wlspwd.txt  
    
    где javaHome – директория c JDK;
          archiveLoc – имя файла для экспорта;
          sourceDomainLoc – директория домена;
          sourceMWHomeLoc – директория в которой развернут MW_HOME;
          domainHostName – хост домена;
          domainPortNum – порт AdminServer-а;
          domainAdminUserName – логин администратора;
          domainAdminPassword – путь к текстовому файлу с паролем администратора.
  5. Скопировать файл экспорта с сервера источника на сервер назначения.
  6. На сервере назначения перейти в директорию:
     $ cd $MW_HOME/oracle_common/bin/  
    
  7. Запускаем генерацию плана переноса домена на сервере назначения:
     $ ./extractMovePlan.sh -javaHome /u01/jdk1.6.0_30  
                   -archiveLoc /home/weblogic/clone_domain/soa_domain.jar
                   -planDirLoc /home/weblogic/clone_domain/plan  
    
    где javaHome – директория c JDK;
          archiveLoc – имя файла для экспорта;
          planDirLoc – директория в которую будет сгенерирован план.
  8. Редактируем сгенерированный план переноса:
     $ vi /home/weblogic/clone_domain/plan/moveplan.xml  
    
    Следует обратить внимание на создание текстовых файлов содержащих пароли к Data Source-ам и указание пути к файлу с паролем для каждого конкретного Data Source-а.
  9. Если требуется, то можно и изменить параметры адаптеров, композитов и деплоймент планов в соответствующих директориях:
     $ /home/weblogic/clone_domain/plan/  
     $ ls -l  
     total 312  
     drwxr-xr-x 2 weblogic app  4096 Mar 14 10:47 adapters  
     drwxr-xr-x 2 weblogic app 12288 Mar 14 10:47 composites  
     drwxr-xr-x 2 weblogic app  4096 Mar 14 10:48 deployment_plans  
     -rw-r--r-- 1 weblogic app 274543 Mar 14 10:44 moveplan.xml  
    
  10. Запускаем импорт домена на сервере назначения:
     $ ./pasteConfig.sh -javaHome /u01/jdk1.6.0_30   
          -archiveLoc /home/weblogic/clone_domain/soa_domain.jar   
          -movePlanLoc /home/weblogic/clone_domain/plan/moveplan.xml  
          -targetDomainLoc /u01/user_projects/domains/clonned_soa_domain  
          -targetMWHomeLoc /u01/ofm/   
          -domainAdminPassword /home/weblogic/clone_domain/plan/domainpwd.txt  
    
    где javaHome – директория c JDK;
          archiveLoc – имя файла для экспорта;
          sourceDomainLoc – директория домена;
          movePlanLoc – имя файла плана переноса;
          targetDomainLoc – директория в которую импортируется домен;
          targetMWHomeLoc – директория в которой развернут MW_HOME;
          domainAdminPassword – путь к текстовому файлу с паролем администратора.

понедельник, 20 февраля 2012 г.

Основы Oracle Fusion Middleware High Availability

Обеспечение высокой доступности это одна из ключевых требований в любом промышленном внедрении. Внедрение систем высокой доступности обеспечивает минимизацию времени простоя системы и максимизацию времени доступности.
Простой системы бывает двух видов:
  • Планируемый – запланированные административные операции;
  • Непланируемый – любой незапланированный сбой.
Оба типа простоя обычно рассматриваются отдельно когда выставляются требования по высокой доступности. Системам необходимо иметь очень ограниченное время к непланируемым простоям и максимально гибко конфигурированными к планируемым простоям.

Табл.1 Планируемые простои и их решения для семейства продуктов Oracle Fusion Middleware
ОперацииРешения
Развертывание и удаление приложенийHot Deployment
ПатчингRolling Patching
Конфигурационные измененияOnline configuration Changes
Change Notification
Batching of changes
Deferred Activation
МасштабируемостьCluster Scale-Out

Табл.2 Непланируемые простои и их решения для семейства продуктов Oracle Fusion Middleware
Тип сбояРешения
Программный сбойDeath Detection and restart using Node Manager for Java EE and OPMN for system components.
Server Clusters & Load Balancing
Cold Failover Clusters
Server Migration
Service Migration
State Replication and Replica aware Stubs
Аппаратный сбойServer Clusters & Load Balancing
Server Migration
Clusterware Integration
Потеря данныхBackup and Recovery
Site DisasterOracle Fusion Middleware Disaster Recovery Solution

Решения высокой доступности можно разделить на два вида:
  • Локальная высокая доступность – предоставляется в одном датацентре;
  • Глобальная высокая доступность – предоставляется в географически различных датацентрах (защищает от региональных бедствий, например наводнений).
Решения локальной высокой доступности можно разделить на два вида:
  • «Активный-Активный» - развертываются на двух или более инстансах, которые улучшают масштабируемость и предоставляют высокую доступность . В данном виде все инстансы работают параллельно. Самым ярким примером является кластеризация.
  • «Активный-Пассивный» - один инстанс (активный) обслуживает запросы, а другой (пассивный) находится в стадии ожидания. В случае выхода из строя активного инстанса все запросы перенаправляются на выполнение на пассивный инстанс, который становится активным. Пассивный инстанс так же называют standby-инстансом.

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