Триггеры объединены для динамической работы в приложении oracle apex
Мне нужно создать рабочий процесс динамического утверждения в приложении Apex, поэтому я создал для этого триггеры. Однако мне нужно объединить их / сделать логику динамической.
Триггер 1 отправляет электронное письмо первому утверждающему для утверждения. Когда утверждающий входит в систему для утверждения, установите p_it_issues.APPROVE_THIS='Y', следующий триггер устанавливает p_it_issues.approved=1, чтобы показать, что он прошел первый уровень. Второй триггер также отправляет уведомление по электронной почте второму утверждающему. (весь код указан ниже для справки). Однако в этом приложении уровни утверждения должны быть динамическими, для одного отдела может быть 2 утверждающих, а для другого - 3. Моя логика на данный момент такова, скажем, у отдела кадров 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... утверждающего n, где n - количество заявок на одобрение для каждого отдела в таблице отделов.
1 ответ
Vini, я считаю, что попытка иметь несколько триггеров в таблице задач будет проблематичной и очень жесткой. Вместо этого я бы создал дополнительные таблицы для управления процессом утверждения.
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 может подсчитывать, если все утверждающие для определенного уровня одобрили проблему, и в этом случае обновите таблицу P_IT_ISSUES с новым уровнем утверждения, и если больше уровней утверждения не установят утверждение как завершенное, в противном случае отправьте на следующий уровень утверждающие.
С уважением, Дэвид