Триггеры, объединенные для динамической работы в приложении oracle apex - PullRequest
Новая
       24

Триггеры, объединенные для динамической работы в приложении oracle apex

0 голосов
/ 29 апреля 2020

Мне нужно создать динамический рабочий процесс утверждения c в приложении Apex, поэтому я создал триггеры для этого. Однако мне нужно объединить их / сделать logi c dynamici c.

Триггер 1 отправляет электронное письмо первому утверждающему для утверждения. Когда утверждающий входит в систему для утверждения, установите p_it_issues.APPROVE_THIS = 'Y', следующий триггер устанавливает p_it_issues.approved = 1, чтобы показать, что он прошел первый уровень. Второй триггер также отправляет уведомление по электронной почте второму утверждающему. (весь код, указанный ниже для справки). Однако в этом приложении уровни утверждения должны быть динамическими c, для одного отдела может быть 2 утверждающих, а для другого - 3. Мой лог c на данный момент, скажем, в отделе кадров есть 2 уровня утверждения. Таким образом, после второго утверждения, когда p_it_issues.approved = 2 и оно соответствует p_it_departments.approval_level (по числу отделов утверждений), установленному как = 2, проблема может быть решена. (Это последнее условие, которое я все еще могу использовать в качестве схемы авторизации, чтобы установить проблему как разрешенную только при совпадении 2).

Но из-за разного уровня одобрения это означает, что мне придется создавать все больше и больше триггеров. Есть ли способ объединить это так, чтобы он продолжал увеличивать и отправлять утверждения из p_it_people.approver = 'Approver 1'.to ..' Ápprover n 'на основе уровня_ утверждений для отдела? У HR есть 2, так что он просто не отправит его 2 утверждающим в таблице p_it_people с установленным в столбце Утверждающим утверждением 1 и 2 соответственно?

Для большей ясности присутствуют мои два триггера и последующие структуры таблицы.

Дайте мне знать, если понадобятся дополнительные разъяснения. Я понимаю, что это кажется длинным и утомительным, но любая помощь будет высоко ценится.

Триггер 1 для утверждения первого уровня: 

CREATE OR REPLACE EDITIONABLE TRIGGER  P_IT_ISSUES_AIU_Notify_Approver_1
AFTER 
insert on P_IT_ISSUES 
for each row 
FOLLOWS P_IT_ISSUES_AIU_EMAIL
declare
v_person_id number;
v_email varchar2(255);
v_dept_name varchar2(50);
begin
select p.person_id ,p.person_email,i.dept_name into v_person_id,v_email,v_Dept_name from p_it_people p,p_it_departments i 
where p.assigned_dept=i.dept_id and i.dept_id=:new.related_dept_id and p.approver='Approver 1'  ;

             APEX_MAIL.SEND( 
                 p_to => v_email, 
                 p_from => v_email, 
                 p_body =>  
                 'You have been assigned a new issue for first level approval.  ' ||chr(10)|| 
                 'The details are below. ' ||chr(10)|| 
                 chr(10)|| 
                 ' Department:'|| v_dept_name ||chr(10)|| 
                 ' Summary: '||:new.issue_summary ||chr(10)|| 
                 ' Status: '||:new.status ||chr(10)|| 
                 'Priority: '||nvl(:new.priority,'-'), 
                  p_subj => 'New Issue for First Level Approval'); 


end;

/

Триггер 2, чтобы установить p_it_issues.approved = 1, когда p_it_issues .approve_this = 'Y' первым утверждающим. 

CREATE OR REPLACE EDITIONABLE TRIGGER  P_IT_ISSUES_AIU_Notify_Approver_2
BEFORE 
update on P_IT_ISSUES
for each row 
declare
v_person_id number;
v_email varchar2(255);
v_dept_name varchar2(50);

begin

if :new.APPROVE_THIS = 'Y'
 then :new.APPROVED :=1 ;
 end if;

select p.person_id ,p.person_email,i.dept_name into v_person_id,v_email,v_Dept_name from p_it_people p,p_it_departments i 
where p.assigned_dept=i.dept_id and i.dept_id=:new.related_dept_id and p.approver='Approver 2'  ;

             APEX_MAIL.SEND( 
                 p_to => v_email, 
                 p_from => v_email, 
                 p_body =>  
                 'You have been assigned a new issue for second level approval.  ' ||chr(10)|| 
                 'The details are below. ' ||chr(10)|| 
                 chr(10)|| 
                 ' Department:'|| v_dept_name ||chr(10)|| 
                 ' Summary: '||:new.issue_summary ||chr(10)|| 
                 ' Status: '||:new.status ||chr(10)|| 
                 'Priority: '||nvl(:new.priority,'-'), 
                  p_subj => 'New Issue for Second Level Approval'); 


end;

Структуры таблиц: Люди: 

CREATE TABLE  "P_IT_PEOPLE" 
   (    "PERSON_ID" NUMBER NOT NULL ENABLE, 
    "PERSON_NAME" VARCHAR2(255) NOT NULL ENABLE, 
    "PERSON_EMAIL" VARCHAR2(255) NOT NULL ENABLE, 
    "PERSON_ROLE" VARCHAR2(30) NOT NULL ENABLE, 
    "USERNAME" VARCHAR2(255) NOT NULL ENABLE, 
    "ASSIGNED_DEPT" NUMBER, 
    "CREATED_ON" DATE NOT NULL ENABLE, 
    "CREATED_BY" VARCHAR2(255) NOT NULL ENABLE, 
    "MODIFIED_ON" DATE, 
    "MODIFIED_BY" VARCHAR2(255), 
    "PERSON_PASSWORD" VARCHAR2(100), 
    "APPROVER" VARCHAR2(50), 
     CONSTRAINT "P_IT_PEOPLE_PK" PRIMARY KEY ("PERSON_ID")
  USING INDEX  ENABLE, 
     CONSTRAINT "P_IT_PEOPLE_NAME_UK" UNIQUE ("PERSON_NAME")
  USING INDEX  ENABLE, 
     CONSTRAINT "P_IT_PEOPLE_USERNAME_UK" UNIQUE ("USERNAME")
    ALTER TABLE  "P_IT_PEOPLE" ADD CONSTRAINT "P_IT_PEOPLE_DEPT_FK" FOREIGN KEY ("ASSIGNED_DEPT")
          REFERENCES  "P_IT_DEPARTMENTS" ("DEPT_ID") ENABLE

Отделы: 

CREATE TABLE  "P_IT_DEPARTMENTS" 
   (    "DEPT_ID" NUMBER NOT NULL ENABLE, 
    "DEPT_NAME" VARCHAR2(255) NOT NULL ENABLE, 
    "APPROVAL_LEVEL" NUMBER, 
     CONSTRAINT "P_IT_DEPARTMENTS_PK" PRIMARY KEY ("DEPT_ID")
  USING INDEX  ENABLE
   )
/

Проблемы: 

CREATE TABLE  "P_IT_ISSUES" 
   (    "ISSUE_ID" NUMBER NOT NULL ENABLE, 
    "ISSUE_SUMMARY" VARCHAR2(255) NOT NULL ENABLE, 
    "ISSUE_DESCRIPTION" VARCHAR2(4000), 
    "IDENTIFIED_BY_PERSON_ID" NUMBER NOT NULL ENABLE, 
    "IDENTIFIED_DATE" DATE NOT NULL ENABLE, 
    "RELATED_DEPT_ID" NUMBER NOT NULL ENABLE, 
    "ASSIGNED_TO_PERSON_ID" NUMBER, 
    "STATUS" VARCHAR2(30) NOT NULL ENABLE, 
    "PRIORITY" VARCHAR2(30) NOT NULL ENABLE, 
    "TARGET_RESOLUTION_DATE" DATE, 
    "PROGRESS" VARCHAR2(4000), 
    "ACTUAL_RESOLUTION_DATE" DATE, 
    "RESOLUTION_SUMMARY" VARCHAR2(4000), 
    "CREATED_ON" DATE NOT NULL ENABLE, 
    "CREATED_BY" VARCHAR2(255) NOT NULL ENABLE, 
    "MODIFIED_ON" DATE, 
    "MODIFIED_BY" VARCHAR2(255), 
    "APPROVED" NUMBER, 
    "APPROVE_THIS" CHAR(1), 
     CONSTRAINT "P_IT_ISSUES_PK" PRIMARY KEY ("ISSUE_ID")
  USING INDEX  ENABLE, 
     CONSTRAINT "P_IT_ISSUES_PRIORITY_CC" CHECK (priority in ('High','Medium','Low')) ENABLE
   )
/
ALTER TABLE  "P_IT_ISSUES" ADD CONSTRAINT "P_IT_ISSUES_ASSIGNED_TO_FK" FOREIGN KEY ("ASSIGNED_TO_PERSON_ID")
      REFERENCES  "IT_PEOPLE" ("PERSON_ID") ENABLE
/
ALTER TABLE  P_IT_ISSUES ADD CONSTRAINT "P_IT_ISSUES_IDENTIFIED_BY_FK" FOREIGN KEY ("IDENTIFIED_BY_PERSON_ID")
      REFERENCES  "P_IT_PEOPLE" ("PERSON_ID") ENABLE
/
ALTER TABLE  P_IT_ISSUES ADD CONSTRAINT P_IT_ISSUES_PROJECT_FK FOREIGN KEY (RELATED_DEPT_ID)
      REFERENCES  P_IT_DEPARTMENTS (DEPT_ID) ENABLE
/

В основном цикличность при отправке писем о триггере от утверждающего 1 ... утверждающего, где указано количество заявок на утверждение для отдела в таблице отделов.

1 Ответ

0 голосов
/ 30 апреля 2020

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

APPROVAL_LEVEL в P_IT_DEPARTMENTS Я полагаю, содержит количество требуемых уровней утверждений (1,2,3, ...).

Я бы создал таблицу пересечений между P_IT_PEOPLE и P_IT_DEPARTMENTS, которая называется P_IT_DEPT_APPROVERS, которая содержит FK плюс APPROVER_LEVEL типа NUMBER. Эта таблица позволяет назначить любого человека в качестве утверждающего для данного отдела с указанным уровнем утверждения. Если APPROVER_LEVEL (из таблицы пересечений) больше, чем APPROVAL_LEVEL (из отделов), то возникнет ошибка.

Я бы создал другую таблицу в качестве таблицы пересечения между P_IT_ISSUES и P_IT_DEPT_APPROVERS, которая называется P_IT_APPROVALS, когда записи, которые пользователь утвердил, и какие записи были утверждены пользователем.

В P_IT_ISSUES я бы включил APPROVAL_LEVEL (NUMBER) для записи текущего уровня утверждения, APPROVAL_COMPLETE_YN VARCHAR2 (1), чтобы указать, что он был утвержден.

Триггер после вставки в P_IT_APPROVALS может засчитать все, если утверждающие для определенного уровня c утвердили проблему, и в этом случае обновите таблицу P_IT_ISSUES новым уровнем утверждения и, если не больше уровней утверждения установите утверждение завершенным, в противном случае отправьте утверждающим следующего уровня.

С уважением, Дэвид

...