metodo aplasar

---------------------aduseradhoc
import EOAW_CORE:LaunchManager;
import EOAW_CORE:ApprovalManager;
Component EOAW_CORE:LaunchManager &c_aweLaunchManager;
Component EOAW_CORE:ApprovalManager &c_aweApprManager;
If &c_aweApprManager.hasAppInst Then
/* Save ad hoc approvers. */
&c_aweLaunchManager.appInst.SaveAdHocs();
End-If;
----------------------------------------------------------------------------------------Hi,
We are on a process to upgrade HCM application to 9.1 and PT 8.52. We are trying
to customize AWE for 'Job Change' transaction to add adhoc approvers by initiat
ing manager or approvers.To do this I have over ridden allowInsert and allowDele
te methods in Adhoc Access Logic class of HR_TRANSFER package to return true, ad
ded Ad Hoc User List and events (On Adhoc Delete, On Adhoc Insert) in 'Configure
Transactions'.
By making these changes we are able to add adhoc approver as an Administrator, b
ut when logged in as approver I see the '+' icon, clicked + to select the potent
ial approver and no approver is added to an approval path.
We further investigated and see that Administrator component is refering to Comp
onent EOAW_ADMIN_MON, Page EOAW_ADM_MON_ACT, SubPage: EOAW_MON_SBP, Record EOAW_
MON_WRK whereas Job Change refers to Component HR_TRANSFER_APPR, Page: HR_TRANSF
ER_EE, SubPage: HCSC_MON_SBP, Record HCSC_MON_WRK. They both differs in the appl
ication packages they use.
Below is a code I have written on HCSC_MON_WRK.EOAW_FC_HANDLER.FieldFormula to i
nvoke the status monitor.
import
import
import
import

HMAF_AWE:ApprovalsFactory;
HMAF_AWE:INTERFACES:IApprovalManager;
HCSC_USERLIST_UTILS:*;
HMAF_AWE:INTERFACES:IStatusMonitor;

/*Declare local object variables*/

Local HMAF_AWE:ApprovalsFactory &AprvFactory;
Local HMAF_AWE:INTERFACES:IApprovalManager &AprvMgr;
Component HMAF_AWE:INTERFACES:IStatusMonitor &monitor;
Component
Component
Component
Component
Component

Record &HdrRec, &MyAttribRec;

string &Action, &Transaction_Name, &CI_Status;
boolean &Call_CI, &EmpInPosition;
boolean &isAdmin;
string &AprvProcId;

&Transaction_Name = "HR_TRANSFER";

&isAdmin = False;
/*Collect the values you need for acting on the transaction*/
Local Record &MyHeaderRec = GetLevel0()(1).GetRecord(Record.HR_TRANSFER_DAT);
/*Create Approvals Factory - We are creating this again so that we are using the
operator set
for the attribute record*/
/*Instantiate the Factory*/
&AprvFactory = create HMAF_AWE:ApprovalsFactory();
/*Instantiate the ApprovalManager object*/
&AprvMgr = &AprvFactory.getApprovalManager("TransferE mployee", &MyHeaderRec, %O
peratorId);
/* If any action is taken, then need to rebuild the approval chain and hide all
these buttons*/
&monitor = &AprvFactory.getStatusMonitor(&AprvMgr.the_ inst, "A", Null);
&monitor.showAll = True;
HCSC_MON_WRK.HTMLAREA = &monitor.buildHTML();
And, below is a code I have written on HR_TRANSFER.adhocAccessLogic application
class:
import EOAW_MONITOR:ADHOC_OBJECTS:adhocAccessLogicBase;
import EOAW_CORE:ENGINE:*;
class adhocAccessLogic extends EOAW_MONITOR:ADHOC_OBJECTS:adhocAccessLogicBase
method adhocAccessLogic();
method allowInsert(&oprid As string, &stepBefore As EOAW_CORE:ENGINE:StepInst, &
stepAfter As EOAW_CORE:ENGINE:StepInst) Returns boolean;
method allowDelete(&oprid As string, &currentStep As EOAW_CORE:ENGINE:StepInst)
Returns boolean;
method allowNewPath(&oprid As string, &stage As EOAW_CORE:ENGINE:StageInst) Retu
rns boolean;
end-class;
method adhocAccessLogic
%Super = create EOAW_MONITOR:ADHOC_OBJECTS:adhocAccessLogicBase();
end-method;
method allowInsert
/+ &oprid as String, +/
/+ &stepBefore as EOAW_CORE:ENGINE:StepInst, +/
/+ &stepAfter as EOAW_CORE:ENGINE:StepInst +/
/+ Returns Boolean +/
/+ Extends/implements EOAW_MONITOR:ADHOC_OBJECTS:adhocAccessLogicBase.al lowInse
rt +/
Local boolean &Adhoc_Insert_Allow;
&Adhoc_Insert_Allow = True;
Return &Adhoc_Insert_Allow;

end-method;
method allowDelete
/+ &oprid as String, +/
/+ &currentStep as EOAW_CORE:ENGINE:StepInst +/
/+ Returns Boolean +/
/+ Extends/implements EOAW_MONITOR:ADHOC_OBJECTS:adhocAccessLogicBase.al lowDele
te +/
Local boolean &Adhoc_Insert_Delete;
&Adhoc_Insert_Delete = True;
Return &Adhoc_Insert_Delete;
end-method;
method allowNewPath
/+ &oprid as String, +/
/+ &stage as EOAW_CORE:ENGINE:StageInst +/
/+ Returns Boolean +/
/+ Extends/implements EOAW_MONITOR:ADHOC_OBJECTS:adhocAccessLogicBase.al lowNewP
ath +/
Return False;
end-method
If anyone can please help if I am missing anything to get it to work so that Adh
oc approvers may be added by originator and by other approvers.Thanks in advance
!
--------------------------------------------------------------Hello All,
Is it possible to setup the AWE for the below situation?
Step 0: Employee A -> A Manager Submit a AWE Request
Step 1: Employee B -> Report Manager of Employee A Check the Workflow Item
----------> If Employee B Approved, then AWE Route to Next Level Chain
----------> If Employee B Deny, then AWE Denied & End
Step 2: Employee C -> A Specific Manager to Check the Workflow Item
----------> If Employee C Approved, then AWE Route to Next Level Chain
----------> If Employee C Denied, then AWE Route to Next Level Chain. (Note: the
denial here is ONLY by Terms, technically in AWE it will still call the DoAppro
ve() method to do the Approve action, however the Deny option will be stored in
a supporting field to indicate if the Employee is Routing the AWE to Next Level
Chain with Approval or Denial option.)
----------> In Short, whatever Action Employee C performed, the AWE Workflow wil
l ALWAYS route to Next Level Chain.
Step 3: Dynamic Employee -> Depend on the Action Employee C in Step 3 above perf
ormed
----------> Employee D
Higher Level Manager (If in Step 3, Employee C Choose to
Deny, ONLY in Terms NOT the AWE Deny Action)
----------> AWE Admin
AWE Administrator (If in Step 3, Employee C Choose to Appr
ove)
AWE Workflow Ends depend on Dynamic Employee (Employee D or AWE Admin) choosing

Approval or Denial in the AWE Process.

I ve tried the following:
#1. Using the Static 3 Steps in One Path (Step 1 -> Step 2 -> Step 3.a -> Step 3
.b), then Adding the Special Criteria on Step 3.a & Step 3.b, such as if the Emp
loyee C Option flag value is marked as Approval, then Step 3.a return TRUE; if t
he Option flag value is marked as Denial, then Step 3.b return TRUE.
Not working for the expected Workflow Approval Chain.
#2.Using Dynamic Step in Two Stage (Stage I: Step 1 -> Step 2; Stage II: Step 3
Dynamic Step), the Dynamic Step 3 is using an Application Class based User List.
And the Application Class is using the custom logic to retrieve the Option Flag
value to determine whether Employee C in Step 2 is choosing Approve or Deny opt
ion, then to determine what list of Approvers to return for the Approver on Step
3 of Dynamic Step.
Not working for the expected Workflow Approval Chain.
Both of the Above 2 approach I ve tested, the result is that at the very first tim
e the Requestor in Step 0 to submit the AWE Request, the AWE initialization logi
c is to do a loop up from the very beginning to the end of the approval chain, a
nd identify all the potential approvers in each Stage/Path/Step. (I ve tried on Dy
namic Step, by default it returns no Approver at the Submit phase, and the Appro
val Monitor page display the Image as Only One Stage, One Path and 2 Steps; Howe
ver, if I hard code an OPRID to return from the Dynamic Application Class, then
after submitting, the Image of Monitor display 2 Stages, one Stage is for 2 Step
s, and another Stage for the Dynamic Step of the Operator ID I hard coded)
I should think there s some sentence in the PeopleBooks mentioned that the AWE wil
l initialize all the Approver on all the Stage/Path/Step at the Submit time. Ple
ase correct me if my memory serve bad.
Is there any way to achieve this AWE Process Logic if utilizing the AWE Setup De
sign?
Current, what I can think of is that, can we use the PeopleCode behind the page
to auto insert an Ad-Hoc Step depend on the Employee C in Step 2 s Action right be
fore/during/after Employee C Clicking the Button?
I ve investigated some Delivered Application Package related to the AWE, however I
didn t see any method name like for Insert Ad-Hoc Step operation. What I can see
is only the check method such as IsAllowAdHocInsert or IsAllowAdHocDelete, etc (
Forgive me if the method name not correct), so my point is that: is that possibl
e for Insert Ad Hoc AWE Step via PeopleCode NOT by Manually Clicking Plus button f
rom the Online Image?
Or any approach can serve this AWE Workflow Logic?
Any input to this post would be very appreciated.
Thanks you in advance if any hint or suggestion :)
Thanks,
Saxon SI
------------------------------------------------------

Hi Saxon, I'm looking to do add an adhoc path during the wf process as well. Not
as complex as yours, but were you able to figure this out? It's been several mo
nths now.
There is a method InsertAdhocParallel() that I'm looking into, located in EOAW_C
ORE.StageInst.OnExecute. I'll reply again with my results.
-------------------------------------------------------------yes its possible to insert adhoc step...try this code
&adhocStateObj.reInit();
&adhocStateObj.stepAfter = &stepInstId; /*pass Step Instance*/
&adhocStateObj.adhocPosition = "serial";
&adhocStateObj.stage = 10; /*pass Stage Nbr*/
&adhocStateObj.thread = &threadid; /*pass ThreadID*/
&adhocStateObj.adhocType = "approver";
&adhocStateObj.oprID = &OPRID; /*NOTE: This will insert only one approver. You c
annot insert multiple approvers*/
EOAW_MON_WRK.EOAW_FU_HANDLER.Value = "insert:";
EOAW_MON_WRK.HTMLAREA = &monitor.updateHTML(EOAW_MON_WRK.EOAW_FU_HANDLE R);
EOAW_MON_WRK.EOAW_FU_HANDLER = "";