Thursday, September 23, 2010

PeopleTools Tips Sample Chapter Available

Are you still trying to decide whether or not to buy my new PeopleTools book? Would a sample chapter help? The McGraw Hill page for this book allows you to download chapter 3 for free. Chapter 3 contains step by step instructions for workflow enabling a transaction using the relatively new Approval Workflow Engine (new in PeopleTools 8.48). If you have ever had trouble configuring AWE and wondered if it was possible to trace the stage, step, path, approver selection information, you will want to take a look at the Tracing AWE sidebar on page 125 (page 35 of the PDF).

96 comments:

Praj Basnet said...

Thanks Jim. I've worked my way through Chapter 3 in your book and it is very informative!

Just a point though, there are some definitions that are created in Chapter 2 as part of web assets that are subsequently used in Chapter 3.

Jim Marion said...

@Praj, I am glad you find the information useful. You are exactly right about the chapter dependencies. Both chapters require a custom component. I wrote the component for chapter 2 and reused it for chapter 3. Many of the chapters build on each other. I included the source projects for each chapter so a reader can skip a chapter and just import its source. For the most part, the sections are independent, but within a section you may find dependencies. Section 2 (Ajax) has the most dependencies. Sections 3 and 4 have fewer dependencies.

Andrew said...

Hi Jim,

I'm wondering if you can help. I've been going through the book (which is really cool btw) and am using the "Configurable User Interface" which is in Ch7. When I use it on Firefox (3.6.10) it works fine. But when I use it on IE (8) all I get is an alert (from part 5 in the APT_UI_LOADER_JS html object).

I'm not really sure what I can do to work out why this is occuring. I've tried adding my site to the intranet zone and trusted zone and changed various options relating to scripting and file downloads.

At first, if I used the IScript directly I'd get a popup prompting me to download the IScript file (unknown file type). But I've resolved this by using the %Response.SetHeader() method, so I can now see the results of the IScript. But I still get the error, so I guess that isn't the problem.

Any hints or clues? All I've been able to do so far is comment out the alert, so at least I don't get the parser error message. But that isn't ideal..

Cheers,

Andrew

Jim Marion said...

@Andrew, What error are you getting? Is it "parser error"? Firefox has a built in JSON.parse, whereas IE requires a custom library. I am guessing that you are missing the JSON2 library. In the chapter 7 iteration of the custom scripts code, JSON2 is imported in PT_COPYURL:

if (!window.JSON) {
// Native JSON not available, so import it
apt.files.importScript({
id: "json2",
url: apt.files.generateScriptContentUrl({
record: "WEBLIB_APT_JSL",
field: "ISCRIPT1",
event: "FieldFormula",
script: "IScript_JSON2"})
});
}

Frank T said...

Hi Jim,
We bought a copy of your book which has been very helpful as I am working on a PeopleSoft Bolt-On app that has AWE embedded into it as the workflow engine.

I extended our ApprovalEventHandler using the sample code in your book as a guide and it works fine to set our transaction’s status when a transaction is fully approved. However, our app is using the LaunchManger DoRestart method, and when the OnHeaderApprove event is extended, the DoRestart doesn't work correctly (the DoRestart seems to be executing the extended OnHeaderApprove logic, but it shouldn't, since when the DoRestart is executed the transaction does not meet header approval conditions). In any event, the end result is that the transaction isn’t restarted successfully and our transaction’s header record is inaccurately set to ‘approved’. Even if I extend the OnHeaderApprove event and don’t include any code in the method, the DoRestart still doesn’t work.
I think this is a bug a
nd I put in a case with Oracle Support but I haven't gotten anywhere with them so far since the rep seems to consider this a customization no matter how I try to explain the issue (even though no delivered code was modified).

Would you be able to confirm whether this is a bug or not? And if it is, maybe you could use your influence to get it fixed. Since our app is component driven, I was able to work around the issue, but I reported the issue because I want to help Oracle improve the AWE framework which overall I think is quite impressive!

Thanks,
Frank

Jim Marion said...

@Frank, I'll forward your comments to the common components team.

Jim Marion said...

@Frank, I did run your information by development. They would like to see a trace file. The developer said to go back to support again, but this time bring a trace file. I suggest you ask for an escalation if the support analyst insists this is a modification. Let me know if you still don't get anywhere.

Frank T said...

Hi Jim,

Thanks for your help in trying to get this resolved. Like I said, I am able to work around the issue for my app since it is component based, but the main reason I put in the case was to try to help Oracle improve the AWE product.

I should be able to put together a trace file, but I balked when the rep mentioned recreating the issue in demo which obviously would not be feasible!

I'll keep you posted!

Thanks again,
Frank

Frank T said...

Hi Jim,

FYI: When I went back and set up a trace for the issue I was having, I discovered that the issue is no longer happening! I had changed some of my code in both the PostBuild and SavePostChange events since coming across this issue, but at this point, I can't really pinpoint exactly what caused the problem in the first place.

Anyway, I assume it must have been something I was doing wrong, but thanks for your help!

Frank

Arvin said...

Hello Jim. Your chapter on AWE is very useful when we created a custom approval functionality in HCM 9/Tools 8.49. But our application will now be migrated to HCM 9.1/Tools 8.5 and initial analysis showed that the AWE in PT 8.5 uses an entirely different set of objects starting with EOAW. Does this mean that we would need to re-code and use EOAW objects rather than PTAF? Thanks!

Jim Marion said...

@Arvin, yes, the only difference is that the 8.48/49 version uses the PTAF prefix and the 8.50+ version uses the EOAW prefix. You will need to find/replace anywhere the PTAF prefix is used. Unfortunately, the PTAF code is still in 8.50, so it will compile even though it is no longer used (at least, that is how it is in my 8.50 server that was upgraded from 8.49).

kevin weaver said...

I am trying to write an approver user list that will return one to many approvers based on the appover's supervisor chain and their supervisor's signing authority. I thought I would just use an application package to return an array of appovers but it is generating an error message. I am afraid I don't quite understand if I can configure one step in a path to have multiple approvers?

Jim Marion said...

@Kevin, yes, absolutely you can do that. In the sample chapter, I show exactly what you are trying to accomplish. In fact, the most simple approval process uses a role for a user list, and a role usually has multiple members.

kevin weaver said...

I was using the wrong Application Package. I used the example from you book as a base and added the logic we needed to determine who needed to approve the transaction. After I got some misconceptions out of my head it was simple. We have two copies of your book here, one for the team and one just for me. Thanks

Jim Marion said...

@Kevin, thank you for the update. Are you using Apps 9.1? The book was written using apps 9.0. In 9.1, all of the AWE classes and tables were renamed with the prefix EOAW. It appears that the developers left the PTAF classes and tables, but they no longer use them. I know this has caused some confusion for my readers. Was this your situation?

Aniruddha said...

Hi JIm The sample chapter on AWE is excellent and we have implemented GL workflow in 9 PT 8.49. The only thing that I see is that the URL that is available on the worklist page takes users to the component. Is there any way that will take users directly to the transaction from worklist page? I was able to concatenate the search parameters to the URL that I am sending in email and that URL takes to the transaction directly. Looking forward to your comments.Thanks

Jim Marion said...

@Aniruddha, the link in the e-mail should take you directly to the transaction without any additional effort. AWE uses the header record's keys to determine the URL. Do your header record's keys match your component's keys?

Aniruddha said...

Yes.
The Component's keys match to those of header record.Component search record has some additional alternate keys.Do you think providing alternate keys will make difference?
For testing i replaced the search record of component with my AWE header record and I see that it is still not taking users to the transaction from worklist directly. The URL in the email also just lists the component and not the search parameters.

I'll keep playing around it and will keep posted.

Thanks

Jim Marion said...

@Aniruddha, interesting. No, the alternate search keys don't matter. I'm not sure why you are seeing this.

Aniruddha said...

The fields in AWE header records were also keys in XREF record. This was causing the worklist issue.(This happened because while adding the fields to XREF record I simply drag-dropped fields from AWE header record)As soon as i fixed it the worklist url started working :)

Thanks to Google:)

Jim Marion said...

@Aniruddha, that makes sense. Thank you for the update!

Raj said...

Hi Jim,
I have a requirement wherein if I do not have a min. of 2 approvers in a approval chain, I have to push it to the Approval Admin. How do I do this?
For checking no.of approvers, I thought of adding a counter during onStepApprove and onHeaderApprove check if the counter in < 2.
If not, I need to error the transaction and send it to admin.
How do I code this in OnHeaderApprove?
Thanks
Raj

Jim Marion said...

@Raj, When you say 2 approvers, do you mean just in the approval user list or 2 people have to approve the transaction?

Raj said...

Two people have to approve the transaction. (not 2 people in the userlist)
I have defined 4 steps (approvers). There is some step criteria also. But at the end, if there is only one valid approver (or only one step is true) then I need to send it to Approver admin.

Jim Marion said...

@Raj, your approach seems reasonable. Also, there is meta-data for how many steps have been approved, etc, so you could dig around and find either the AWE properties for it or the actual meta-data and SQL test it.

Raj said...

But I am not able to figure out how to direct the transaction to the Admin in case the approver condition is not met.

The AWE send the transaction to the Admin when it does not find any approvers. Is there any event out there which can be leveraged?

Jim Marion said...

@Raj, dig around in the PTAF or EOAW (depending on your release) app classes and see if you can find a way to cancel the approval and then add a new addhoc approver or something. There should be existing methods for both of those. Work backwards from EOAW_CORE:ENGINE:AppInst.

Suhas said...

Jim

Chapter 3 is very helpful as we are building custom promotion process.

We are facing problem in inserting adhoc approvers to our process. by using piece of code mentioned in book "+" sign appears on status monitor page.

But on selecting adhoc approver userid and returning back to approval confirmatin page, adhoc approver disappear.

Helping People Succeed said...

Is it possible to generate a AWE transaction from one portal (e.g. External) and then generate the link for approval from a another portal (EMPLOYEE)?

For e.g. - our users are in external portal (EXTERNAL), but the approvers are in EMPLOYEE portal. So when the email is generated for approval, we want to the use the EMPLOYEE portal. But the URL defaults to the EXTERNAL portal..

Using of the Internal URL definition also did not work..

Any ideas...

Jim Marion said...

@Helping, take a look at PS_EOAW_TXN. In there you will find EOAW_EXT_URL, EOAW_INT_URL, NODE, and PORTAL. Likewise, look at the EMP_SERVLET URL definition. Often these values are not populated. I don't believe any of these are used when you execute a transaction online (only from web services, app engine, etc), so it probably won't help you, but this is all I can think of.

You should put in a ticket with Oracle Support to see how they recommend resolving this.

prashant gupta said...

does tools have any table which stores the list of all approvers for a particuar request?

Jim Marion said...

@prashant gupta, PSWORKLIST stores all the approval information for both traditional and AWE approvals. You can see multiple approvers for a particular transaction ID by querying for that transaction ID.

Sapna said...

Hi Jim,

I am working on thr AWE set up for PO change order.
In Financials, on the PO and eProcurement Approval setup, the Transaction Registry only really takes Header and Line level, but the trouble is a lot of the workflow decisions need to be based on the lowest level ie distribution, where the chartfields are. for example, routing by department, project, account.my client want the routing to be sent out based on the diff department on distribution level for a single PO line .THis is what i would expect to be able to configure.

So, for example PO - the Transaction Registry expects two views PO_HDR_AW_VW and PO_LINE_AW_VW. If you put a dist level view on the 2nd level the system crashes down the line in an approvers worklist. If i modify the line view adding in the PO_LINE_DIST table you also run into problems and you can see from the peoplecode that its only populating the PO_LINE_AW_VW from the PO_LINE table
.
Is there a way my requirement is achiveable.Please suggest.

Jim Marion said...

@Sapna, couldn't you create an approval user list that is either a query or an app class? The approval user list would take the header/line info as parameters and look up the distribution department from the header/line details. It would then determine the appropriate approvers and return them as either query results or as an array.

Tom Williams Jr. said...

Hi Jim.

I wanted to thank you for your very informative blog. I have been reviewing it for months now and have finally sined up so I can leave comments.

As a result of this blog entry I will buy your book as I am currently configuring AWE on HCM 9.1.

Could you provide a blog entry on troubleshooting delivered AWE processes? We are exeriencing some strange errors that I have not found documented and figure if I had a good review to follow it might help. We are currently configuring AWE on Recruiting and JobOpening is the Process ID.

Thanks again...

Tom

Jim Marion said...

@Tom, thank you for the compliments. As for the AWE troubleshooting, did you see the AWE log configuration sidebar in the sample chapter attached to this post?

Sapna said...

Tom,Yes correct i am able to do that with the query and App package but the problem with this is If there are three distribtuion line in one PO line then it will combine the department approvers from all the three distribtuion line into one path (Line)and route it.My requirement is to somehow create paths for each distribution line for a single PO line.This is the part i am not able to work with.Please suggest if there is any way to do so.

Raj said...

Sapna,
Can you not create 3 paths with different path criteria's such that the logic will follow only one of the paths? This way you can have different set of approvers for each path.
The criteria can be coded in app.class which will return true or false.

Sapna said...

@Raj,thanks for replying.
I appreciate it..yes i could have done this if the number of distribution lines are fixed for a PO line.I can setup paths criteria on the basis of distribution number only for a fixed number.but there can be any number of distribution line number for a PO so i have to dynamically generate as many paths as many the distribution lines are.I took the three distrbtuion line as an example.

Thanks!!

Tom Williams Jr. said...

@Jim. I don't think I understand what you are asking me to look at. Sorry if it seem so obvious. I do not have the ability to customize any of the delivered packages to do this analysis at this point. They are pretty restrictive here and I cannot change delivered processes for some of the logging items you pointed out in the attached article.

Raj said...

Sapna,the other way to try this is to have one path and create the approval defn. with max. no of approvers. Then use an app.class in the step criteria to determine whether to use that step approver based on the data from distribution line. So based on some criteria you can turn on or off executing any of the step. This will finally leave you with the required no. of approvers.

Jim Marion said...

@Tom, yes, that is correct. You would have to make a modification to enable the logging discussed in my book. Other than that, I'm not aware of any techniques for debugging workflow rules.

suma said...

Sapna, Can u tell me how u have implemented it .. I am also in same issue ...
Jim , can u please pore some ideas on it

Sapna said...

Hi Suma,

We changes the AWE base tables to include the key fields from the distribution level to achieve this.We modified the PO_AW along with the line level record used in the AWE transaction registry.It required many other changes in the AWE approval component to include the extra fields we added in the Configuration records but It worked:)

Kevin Weaver said...

Hi Jim, I have an intresting issue with AWE delegation. We are applying bundles and our batch delegation is failing on some old time cards that got stuck due to some bugs in the TL process that would not let the manager approve them. Now these outstanding transactions are being assigned to delegates and then reassigned back during the batch delegation process and are failing. Needless to say they are from last year and have been manually entered into the time card and I would be helpful to just mass deny all these transaction, since they have already been paid. I looked at the admin component and have determined that the best way to get rid of these transactions would be to write a batch process to deny these old transactions. Is there way to go against the core application package to acheive this? Thanks Kevin

Jim Marion said...

@Kevin, good question. It has been a long time since I've looked at the EOAW (or PTAF depending on your release) tables, but I would be tempted to just SQL update the status flag on those items you want to remove.

Yes, you can use the ApprovalManager to Deny transactions. The ApprovalManager constructor requires an Operator ID, so you may be able to pass in the OPRID's of the users owning the offending workflow items. But this approach should run the same code that is failing and should respond the same as if you ran it online.

Krish said...

Hi Jim, I have a strange requirement from one of the clients to cancel the transaction post approval due to exceptional reasons. Can we terminate or suspend a transaction once the approval process is complete. i.e all the steps are approved but, post all the approvals can the transaction be cancelled. Currently i have defined a process and definition for approvals and to cancel the transaction post approvals i have defined another process. i.e post approval i would resubmit the transaction and then terminate it immediately.


But to maintain consistancy in the approval monitor for the user this is not the right solution.

Could you suggest a solution or any other work around.

Jim Marion said...

@Krish, I'm having some trouble with the concept. If I understand correctly, you would like to cancel a transaction that was approved. I am not aware of a good way to do this. The point of approval is to confirm a transaction. Once confirmed, it should not need canceling. If it does, then someone should question why it was approved. The reason you don't cancel an approval is because of the transaction associated with that approval. An approval is like a dam on a river. The dam holds back the water. An approval holds back the transaction. Once you approve the transaction, that is like opening the flood gate for the dam. The transaction flows out to the other side. Trying to unravel the transaction and all other business processes linked to the transaction may be just as dangerous as standing in front of the flood gate to push flooding waters back behind the dam.

I understand that circumstances change and a previously approved transaction may no longer be acceptable, but that should be so infrequent that you would forget how to handle it if you didn't write it down in policy form.

If you find that canceling an approval is becoming a common business practice, then perhaps your workflow needs to be redesigned so that it has another level of approval, and that level of approval involves whomever or whatever is later deciding to cancel the approval.

PeopleSoftOracleFusion said...

Hello Jim, We are implementing AWE for 'Adhoc Salary Change' in 9.1/8.5 and my question is around selection of HDR record.

Can we choose HDR record at any level other than zero? We believe we should keep 'SS_KEYS' at level 1 as header record and populate the value of status into SS_STAT_INDICATOR as this is the field value workflow looks at to invoke CI to update database one all approvals are met. In that way, we don't need to add any exclusive field to keep track of approval/submit status.

Also, can we use a combination of HMAF_AWE application package and HCSC_MON_SBP rather than EOAW_CORE and EOAW_MON_SBP for HCM 9.1/8.5 application as both application package differs the way they are implementing AWE engine. To start with, we are trying to implement the basic AWE functionality in 'Adhoc Salary Change' and once we have a proof of concept working, then will expand to meet customer requirements.

Thanks in advance.

Jim Marion said...

@PeopleSoftOracleFusion, yes, use the HMAF classes, not the EOAW classes.

As far as the HDR record... the header identifies a unique row for the approval. AWE knows about headers and lines based on configuration, but doesn't really care about level 0, level 1, level 2, etc, the way the component processor cares about them. AWE is all PeopleCode, so you can pass it a stand alone rowset, etc. Where the fields exist on the page is irrelevant. What matters is that you initialize it with the same header record that is identified in the meta data as the header record. And, if you use line level approvals, that you use the same line record.

PeopleSoftOracleFusion said...

Thank you, Jim. I got another question. In reference to Chapter 3 of your book, In ApprovalEventHandler, we are updating the value of APT_WA_APPR.APPR_STATUS = 'A'. By updating this APT_WA_APPR.APPR_STATUS to 'A' is not updating AWE record statues to 'A' for the below fields or any ohter record.fields specific to AWE. How should be invoked so that underlying AWE records also gets updated.

PS_GMCR_SALCHG_XRF.EOAWTHREAD_STATUS
EOAWSTEP_STATUS.EOAWSTEP_STATUS
PS_EOAW_USERINSTEOAWSTEP_STATUS

Jim Marion said...

@PeopleSoftOracleFusion, you should not have to update the EOAW tables directly. You just call the ApprovalManager.DoApprove or ApprovalManager.DoDeny methods. AWE takes care of updating the EOAW tables and calls your Approval Event Handler.

You might turn on an SQL trace to see if it is updating the tables and then rolling back or something. You might also turn on the AWE specific trace as described in the Chapter 3 sidebar on page 125.

Omar Iqbal Naru said...

I have a scenario in which I have to create an AWE workflow with dynamic paths. I have set up the trace. The trace works fine when the process is initiated and the request is assigned to the first approver but after the first approver approves, the trace doesn't show anything.

I am using worklist for notification. The item does get removed from the first approver's work-list but is not added in the second approver's worklist. I have tried to debug and see that whether the user-list method is called again and found out that it doesn't get called twice.

I am using an application engine class for userlist.

Please let me know what I am missing.

Jim Marion said...

@Omar, I saw your question in the OTN Forum here. Perhaps another reader of this blog has a recommendation for you?

Omar Iqbal Naru said...

If you could refer me to a generic step-by-step guide for configuring a dynamic work-flow it would be great as I wasn't able to find anything regarding dynamic work flow. The red-paper that I read also focused on static work-flow.

Let me add some more information about my scenario:
1 - Create a single step+single path process with source set to dynamic and all criteria set to always true.
2 - As it is a single step I will use the same user list based on an application class as the user list for the step.
3 - I have added a field in the transaction record which helps me store the approval step number i.e. how many approvers have already approved this request. In the user list class, I use this field to join with a custom table to determine the user id of the approver to which the transaction next has to be routed. For example
current-seq-id = 1 - approver = test1
current-seq-id - 2, approver = test2

I have created 3 events for the transaction with one being route for approval and the participants were the approvers from the drop-down.

I hope this additional information helps you in identifying the issue and helping me. :)

Thanks!

Raj said...

I don't think the dynamic feature works. Check with oracle support.

Raj

Praveen said...

Hi Jim
Do you have anything on line level approval implementation?

Jim Marion said...

@Praveen, I do not.

das said...

Hi Jim, Thanks for all sharing all the knowledge.
I have a question in userlists.
I am writing App Package to get a list of users. The users have multiple roles and each user from the list should Approve the voucher..ie., the multiple oprids fetched by the userlist should be in different boxes...but for me all the users are coming in a single box. Can you please help me how to make this multi-tier approval instead of multiple approvers. FYI, I am using almost the same logic you used in the book to get the userlist.

Jim Marion said...

@das, I believe what you want is multiple steps instead of a list of approvers for a single step. Are you able to configure a static number of steps or is that variable by user? It has been a few years since I looked into AWE, so I can't remember how to make a dynamic path.

das said...

Thanks for reply Jim. My basic problem I am fetching the approvers from a custom table and incase for a particular role if the approver doesn't exist it has to fetch the next level supervisor. If we do this by delivered configiration there will be box as SKIPPED which is not acceptable by the client. So we are getting approvers with multiple roles and if we use this the same role might come in different step and this again can come as SKIPPED.

Prakash said...

Hi Jim, I purchased your book and currently I'm working chapter 3. Followed your instructions and receiving 'No approval process of id APT_WebAssets is registered with the system.' message when I tried to launch component. Verified in Register Transaction page and APT_WebAssets exist.

Please can you help me?

Thanks,
Prakash

Jim Marion said...

@Prakash, are you on PeopleTools 8.48/49 and apps 9.0 or are you using apps 9.1+ with PT 8.50+? The chapter for the book was written using 8.49 with 9.0 apps. In 9.1, the common components team renamed all of the App Designer objects to be EOAW instead of PTAF. If you followed my steps on a newer version of PeopleSoft, then you may have updated the wrong tables and used the wrong app classes. Depending on your tools release, be sure to use EOAW or PTAF accordingly. EOAW on newer versions, PTAF on older versions.

Mktablet said...

Hi Jim,
Thanks for your help on AWE.My question is more specific to the delegation piece. I have created the custom transaction as per your book and now I am planning to use delegation on top of it. After defined the delegation setups the transaction still does not flow to the new proxy and still stays with old approver. so
1) Do I have to write a custom code in userlist to replace this? The delegation process as such works fine.
2) Where would u suggest to call CI after all approvals are done? In our case lets say if all approvals are approved by monitor approval process. I should be able to call CI on final approval. Is there a delivered class I can use?

Jim Marion said...

@Mktablet, For question #1, I'm actually not familiar with delegation. I know it exists, I know what it does, but I haven't looked into configuration or design. You may want to post that question on the PeopleSoft General Discussion OTN Forum. For #2, what you need to create is an Approval Event Handler as described in this chapter, but use the OnFinalApproval event. I'm suspecting you already knew that though... Let me know if I misunderstood the question.

Jim Marion said...

I believe this is the answer to the question raised by @Mktablet: OTN Forum Thread: Delegation Framework -- AWE

Mathumitha said...

Hi Jim,

I have a requirement in which the awe has 2 paths and each path is independent of the other(approving/denying path 1 should not affect path2). The approval is header level. Can this be done through peoplesoft AWE and how can this be implemented.

Thank you

Jim Marion said...

@Mathumitha, in parallel? Yes, this can be done. Just add a new path in the "Setup Process Definitions" component.

Rahul Patil said...

I have enabled Ad-hoc approval.
But once I modify the approval & add some approvers manually it does not save the changes.

Do I need to write any peoplecode to save ad-hoc approvers ?

Jim Marion said...

@Rahul, no you just have to change the "A" to a "D" as you probably did.

Kevin Weaver said...

I saw mktablet's Question out here and thought, what a great idea for a blog. I just added Delegation Framework to approve my custom AWE transaction, so I documented the steps here...

http://pskcw.blogspot.com/2013/05/delegation-frame-work-for-approving.html

Jim Marion said...

@Kevin, thanks for sharing!

Allen Kuruvilla said...

Hi Jim,

I am bit confused with the concept of Include Users as Input and Transaction Keys as Input in the User List definition which is used, if your User list is a sql definition

Can you throw some light on this topic?

Thanks & Regards,
Allen

Jim Marion said...

@Allen, you may want your user list to return different users based on transaction keys and the OPRID of the prior approver (or the originator). If you check one or both of these boxes, then the values from the transaction are used as bind variables for the SQL statement. You only need these values if the transaction affects the user list. If so, then you would join a table like PSOPRDEFN or PSOPRALIAS to a transaction table and then add bind variables to the transaction table fields that match the keys you expect. I believe the keys are based on the header record registered in the AWE meta-data, and follow the order of the header record. These also match the AWE xref record.

Mktablet said...

@Kevin Weaver @Jim Marion . Thanks for the info.

Thanks,
Manoz

Deepak Ray said...

Hi Jim.. The chapter 3 is really very much helpful to have an understanding and insight of AWE. I have gone through the Oracle Red Paper also and found that they have used HSCS app packages / classes but in the chapter you have used PTAF app packages / classes..

Could you please clarify if the app packages have specific purpose or we can use any one of them..

Thanks,
Deepak Ray

Jim Marion said...

@Deepak, in PeopleTools 8.48 and 8.49, the core AWE objects were prefixed with PTAF. HCM created their own abstractions of AWE that use the prefix you identified. These were sub classes of the PTAF app classes. HCM recommends that you use their abstractions. Just FYI, in PT 8.50, AWE was moved to common components/enterprise components and all of the object prefixes were changed to EOAW.

Deepak Ray said...

Thank you Jim for the information. I am using peopletools 8.51 and was able to carry out the example by you by changing the PTAF Packages to EOAW. I would now try out with HSCS packages.

Could you please suggest how can we invoke a CI once the workflow is approved.. do we need to put the ci code in the onFinalApprove method? its just my guess.. or is there any setup in AWE like we have in Integration Broker --> Service Operation --> Implementation

Jim Marion said...

@Deepak, you do not need to use the HSCS. If you have it working with EOAW, that is good enough. This is what PeopleTools and common components intended for you to use. HCM has an abstraction layer, but you don't need to use it.

Yes, use the onFinalApprove method for your CI. Just create and use the CI in that method of your event handler. No, there is no Integration Broker setup. Integration Broker is only involved if you are communicating with an external system. Using an HCM CI from HCM does not involve Integration Broker.

Mathumitha said...

Hi Jim,

I am doing an AWE configuration. There are 3 steps in which step 2 and step 3 have some criteria. For few transaction, the step 1 is skipped as there are no approvers. But the step 2 even though the criteria is not satisfied is included in the approval process. What may be the reason for this

Jim Marion said...

@Mathumitha, I don't see any logical reason it should behave like that. You should open a support case for this issue.

Kirthi Sistla said...

Jim,
In the above comments I see that you suggested using the CI in OnFinalApproval method of the event handler. I see that there is only OnHeaderApprove method delivered within the app packages. Do we need to instantiate the CI in OnHeaderApprove method of our custom event handler class.

Jim Marion said...

@Kirthi, it depends on what you are trying to accomplish. OnFinalApprove is the method that is called when all approvals are complete. If that is what you want, then you can create the method. If you just want to call the CI in the same place as the delivered code, then, yes, use the OnHeaderApprove.

Kirthi Sistla said...

Thanks Jim. I was able to create a new class for CI within the custom app package and called the ci methods from OnHeaderApprove .until now there are no issues.

Thanks,
Kirthi

Kevin Weaver said...

Jim,

I am trying to add reviewers to an approval step and it works great if the transaction only goes through that stage.

So to clarify, I have an AWE approval process that contains multiple stages, one is for Compensation Team to approve if the Job Requisition is over a certain dollar amount and the other stage is for the manager's approval. What I am seeing is the reviewer user list is working fine if the transaction does not require approval from the compensation team, but if it does require the compensation team's approval then the review list is totally ignored. I even put code in the reviewer user list to email me when it gets called and it is not even getting called when the transaction requires multiple stages of approval. I have a case open with Oracle, but I thought I would ask you if you have ever seen this behavior before?

Thanks!

Kevin

Jim Marion said...

@Kevin, can you set it up as two separate stages, but repeat the manager's approval step in both stages? Then if the Compensation team criteria is met, then it will choose that stage. Otherwise, it will just use the manager stage. I really can't remember if it is supposed to execute all stages that match or just pick the first one that matches.

Kevin Weaver said...

That is how I first attempted to configure the approvals, but I also wanted to skip prior steps for Requester and if the requester was a manager of someone within the compensation team it would skip their approval. So I moved them to their own stage and that worked for approvals, but is is not working for the reviewer list. We are really using the Compensation team's approval to clean up the jobcode description so that the job is ready to post, based on the transaction.

Chandra said...

Jim,
We have a need to change the email link in the emails generated by AWE code (EOAW_Txn) or something else. Is there a way to change the email only where we need not altering the system wide changes ? I prefer not to change the code EOAW_CORE packages.

appreciate your suggestion.

I met at you HIUG conference at Phoenix, Thanks again for supporting me on PSUNIT presentation.



Jim Marion said...

@Chandra, what types of changes do you want to make?

Vish..... said...

Hi Jim,

This is the first time I am trying to implement AWE. I have done everything as per the steps you have mentioned in your book. It works fine for email notifications. But as soon as I enable the Worklist and try and save the component it gives me the following error:

at Approval process instance (Id = 'UC_TREMISSION', Definition ID = 'UC_TREMISSION', Effective date '2014-02-03', Thread id '513') (236,1056):10:1, Step nbr 1 (236,1058) PTAF_CORE.ENGINE.DefStepInst.OnExecute Name:Activate PCPC:8036 Statement:114
Called from:PTAF_CORE.ENGINE.PathInst.OnExecute Name:Launch Statement:68

I have researched on this error but I am not sure what is causing this. Is there any configuration I am missing? The users to whom the worklist is routed has worklist enabled in their user profile.

Jim Marion said...

@Vish, are you on apps 9.0 or 9.1+? 9.0 used PTAF_% whereas 9.1+ uses EOAW+. If you are on a newer release, then redo all the steps you did before, but instead of using PTAF App Classes and record definitions, use EOAW app classes and record definitions.

Vish..... said...

Hi Jim,

We are still on HCM/CS 9.0 and PT 8.51.

Thanks

Ank's Blog said...

Hi Jim,

I have a peculiar issue with AWE. We have around 4 steps in our workflow. There are few approvers who are same in step 3 and step 4. Our requirement is that if A approves at step 3, A should not be able to approve at Step 4. I have created a Query for populating userlist on who has already approved, and the userlist is fine at database end but userlist is not updated accordingly.

Thanks,
Ank

Jim Marion said...

@Ank, like you said, it should be based on your approval user list. If it is not working that way, then you should file a support request, because I believe that is the way it is supposed to work.

Vish..... said...

Hi Ank,

The userlist is decided as soon as the transaction is submitted. So while submitting the transaction, the approval status is pending, so your user list query will always pull the same user list at level 3 and level 4. You can have auto approval checked so that when user approves at level 3 it is auto approved at level 4. The other way is to determine the userlist from the code and not from the query. If somehow you can determine the user at level 3 and the user at level 4, then u can return null if user at level 3 is same as user at level 4. If level 4 is the final step then in this case information will be routed to Admin Role defined while setting up the process definitions. If step 4 is not the final level then it will just skip the step and it will show Skipped in the approval status monitor.

Krish said...

Hi Ank,

I think your requirement is if A approves at 3 then at 4 other than A has to approve the transaction. If so you can have the dynamic step checked. In Dynamic step the next approver is decided after the current step is approved. Even in the monitor until step 3 is approved you cannot see the step 4 approver name. I guess this should solve your issue. Refer Peoplebooks for more info on Dynamic steps.