Jak utworzyć użytkownika Apex z joba?

Witajcie,

Mam pytanie. Z konsoli sql na apex.oracle.com wykonuję taki kod:

apex_util.create_user(p_user_id => rec.user_reg_id, 
                      p_user_name => rec.login,
                      p_email_address =>  rec.email_id,
                      p_web_password => rec.password);

i on działa prawidłowo bez żadnych błędów. Natomiast gdy ten sam kod wrzuciłem do schedulera dostaję:

ORA-20001: Package variable g_security_group_id must be set. ORA-06512: at "APEX_230200.WWV_FLOW_IMP", line 109 ORA-06512: at "APEX_230200.WWV_FLOW_IMP", line 145 ...

Próbowałem ręcznie ustawić tą zmienną pobierając ID z workspace ale nic nie działa. Gdzieś na SO doczytałem, że trzeba nadać odpowiednie uprawnienia dla schedulera ale nie było szczegółów czy chodzi o grant execute pakietu, który uruchamia powyższy SQL czy jakieś uprawnienie po stronie definicji aplikacji. Możecie coś podpowiedzieć bo zaczynam wymiękać z tym tematem.

Ej no, wpisz komunikat błędu (ten pierwszy) w Google i pierwsze dwa linki zawierają rozwiązanie.

ale ty doczytałeś mojego posta do końca, żę próbowałem tych metod i nie działają?

@woolfik: a która wersja i czego? :) Oracle, APEX. Jak tworzysz tego joba? Jak pobierasz tego IDka z worskepace? Czy faktycznie pobieranie zwraca coś?

Ja bym poszedł najpierw prostym tokiem rozumowania:
a) Z konsoli, gdzie create_user działą -> select user from dual (użytkownik na którym działa) i z tego pobrał security group.
b) Utworzył joba wykonywanego w kontekście użytkownika z pkt. powyżej

Zgodnie z randomową wersją dokumentacji APEX do create_user możesz jawnie podać listę security groups. Może to coś zmieni?

@yarel: próbowałem tak jak jest to na SO oznaczone natomist przy takim JAWNYM ustawieniu

procedure RegisterUsers is
    l_workspace_id      number;
  begin
    l_workspace_id := apex_util.find_security_group_id (p_workspace => '<<WORKSPACE>>');
    apex_util.set_security_group_id (p_security_group_id => l_workspace_id);     
--                          

dostaję takie coś:

ORA-20987: APEX - User APEX_PUBLIC_USER requires ADMIN privilege to perform this operation. - Contact your application administrator. ORA-06512: at "APEX_230200.WWV_FLOW_ERROR", line 1111 ORA-06512: at "APEX_230200.WWV_FLOW_ERROR", line 1569 ORA-06512: at "APEX_230200.WWV_FLOW_FND_USER_INT", line 108 ORA-06512: at "APEX_230200.WWV_FLOW_FND_USER_INT", line 1737 ORA-06512: at "APEX_230200.HTMLDB_UTIL", ...

Czyli procedura leci z bazodanowego użytkownika APEX_PUBLIC_USER, żeby to zadziałało, to user powinien mieć uprawnienia ADMIN do workspace <<WORKSPACE>>.

Strzał: grant APEX_ADMINISTRATOR_ROLE to WOOLFIK; i wykonaj procedurę jako użytkownik WOOLFIK.

no ale zobacz ... z mojego usera WOOLFIK gdzie jestem adminem tej aplikacji ten kod wywołuje się bezproblemowo. Mormalnie z konsoli SQL na apex.oracle.com dodałem schedulera:

DBMS_SCHEDULER.create_job(...)

i normalnie w

select * from user_scheduler_jobs 

tego job'a widzę. w Client_ID jest moja nazwa usera ale w JOB_CREATOR jest APEX_PUBLIC_USER. Nie mogę (albo przynajmniej nie chcę) dawać userowi APEX_PUBLIC_USER granta administracyjnego do mojej aplikacji bo wtedy każdy kto ma tam konto używając durnego schedulera będzie mógł ingerować w mój workspace ... dlatego chciałbym uruchomić schedulera na koncie WOOLFIK ale nie mam pojęcia jak go do tego zmusić.

Nie wiem jak tego joba tworzysz, ale może podpięcie credentiali wystarczy do uruchomienia w określonym kontekście?

BEGIN
  DBMS_CREDENTIAL.CREATE_CREDENTIAL(
    credential_name => 'WOOLFIK_SECRET',
    username        => 'WOOLFIK',
    password        => 'WOLFIK123'
  );
END;
/

 DBMS_SCHEDULER.CREATE_JOB(
 ...
 credential_name => 'WOOLFIK_SECRET',
 ...
);

@Yrael: no to teraz mam tak:

ORA-27351: conflicting values of job attributes CREDENTIAL_NAME and JOB_TYPE

Nie wiem czy te credential nie jest przypadkiem do typu executable i uruchamiania skryptów po stronie serwera

No to można jeszcze próbować to obejść.

Obecnie:
APEX_PUBLIC_USER tworzy joba -> job wykonuje się w kontekście APEX_PUBLIC_USER -> leci błąd, bo APEX_PUBLIC_USER nie ma uprawnień do administrowanie workspacem.

Obejście:
Zapakować logikę joba do procedury, która wykonuje się z prawami (AUTHID DEFINER) tego kto definiował (tu procedure będzie tworzona w schemacie WOOLFIK, który ma uprawnienia adminsitracyjne do workspacea).

create or replace procedure add_user
   AUTHID DEFINER
as begin
   ...
end;
/

Grant execute dla APEX_PUBLIC_USER na tej procedurze i powinno śmigać.

Inne obejście:
Zamiast joba, z APEX_PUBLIC_USER wrzucasz message do kolejki AQ, a konsument zaczytuje z kolejki i wykonuje z odpowiednimi uprawnieniami.

Jednak się pospieszyłem ...

ORA-20001: Package variable g_security_group_id must be set. ORA-06512: at "APEX_230200.WWV_FLOW_IMP", line 109 ORA-06512: at "APEX_230200.WWV_FLOW_IMP", line 145 ORA-06512: at "APEX_230200.WWV_FLOW_FND_USER_INT", line 1735 ORA-06512: at "APEX_230200.HTMLDB_UTIL", ...

success miałem ponieważ w międzyczasie ręcznie uruchomiłem procedurę i job nie miał nic do roboty więc się uruchomił i skończył działanie z wynikiem success ...

Schemat WOOLFIK.ADD_USER <-- procedura zdefiniowana w schemacie, który ma uprawnienia ADMIN oraz z "AUTHID DEFINER" (nie z AUTHID CURRENT_USER)
AUTHID CURRENT_USER spowoduje wykonanie w kontekście tego kto dodał joba (czyli będzie to najprawdopodobniej APEX_PUBLIC_USER). Wcześniej pisałeś, że zrobiłeś z AUTHID CURRENT_USER :-)

@Yrael: info dla Ciebie ale mam nadzieje też dla innych, z podobnym problemem. Z racji tego, że wspieram inny projekt na apexie komercyjnie to skorzystałem z okazji, że mamy w cenie polski i dość responsywny support od oracle i zadałem chłopakom to pytanie. Odpowiedź poniżej:

Rozumiem use-case I ma to wszystko sens ale niestety nie mam dobrych wiadomości.

Ze względu na fakt że "apex.oracle.com" to środowisko wspóldzielone jest one ograniczone z punktu widzenia bazy danych. To znaczy że nie ma tutaj możliwości tworzenia/zmieniania użytkowników bazodanowych jak I również w tym przypadku korzystania z niektórych paczek które wymagają autoryzacji na wyższym poziomie, jeśli job był tworzony bezpośrednio w APEX-ie, spróbowałbym jeszcze powtórzyc te same kroki z SQL Developer Web ale w przypadku instancji na "apex.oracle.com" wyniki powinny być takie same.

Najlepszym rozwiązaniem w tym wypadku byłoby skorzystanie z ADB-S (Always Free) i używanie jej jako środowiska testowego.
Dodatkowo dodam że jak pewnie Pan już słyszał APEX 23.2 jest oficjalnie dostępny, więc istnieje też możliwość zainstalowania go lokalnie.