peoplesoftawe开发资源-CSDN文库

4星 · 超过85%的资源需积分: 50 141 浏览量 2011-07-05 09:59:22 上传评论 1 收藏 3.39MB PDF 举报

### PeopleSoft AWE 开发详解 #### 一、引言在企业级应用开发领域，Peoplesoft 作为一款强大的企业资源规划（ERP）软件，为各种规模的企业提供了高效的业务流程管理和自动化工具。其中，Approval Workflow Engine (AWE) 是 Peopelsoft 体系中的一个重要组成部分，它为企业的审批流程提供了高度定制化的解决方案。本篇将围绕 AWE 的发展历程、工作原理、应用场景以及开发指南等方面进行深入探讨。 #### 二、AWE 发展历程与概述在 Peoplesoft 8.48 版本之前，Peoplesoft 使用的是 Virtual Approver 框架来处理审批流程。随着技术的进步，Peoplesoft 在 8.48 版本中引入了全新的 Approval Workflow Engine (AWE)，并在 9.0 版本中将其广泛应用到各个模块中。最初，AWE 主要是为了 Peoplesoft 的 Supply Chain Management 模块而设计，但在后续版本中逐渐扩展到了其他模块，并成为了一个核心组件。 #### 三、AWE 的工作原理与特点 ##### 3.1 工作原理 AWE 采用了一种灵活的规则引擎来实现复杂的审批流程。它可以处理从简单的单级审批到复杂的多级审批，并支持基于条件的路由逻辑。例如，在采购订单的审批流程中，对于不同金额的订单可以设置不同的审批路径：小金额订单可能只需要经理级别的审批，而大金额订单则可能需要高级管理层的审批。 ##### 3.2 特点 1. **灵活性**：AWE 支持高度定制化的审批流程，可以根据具体需求定义复杂的规则。 2. **集成性**：AWE 与 Peoplesoft 的其他组件紧密集成，使得开发者能够轻松地将审批功能嵌入到现有的业务流程中。 3. **扩展性**：AWE 可以通过 API 与其他系统集成，支持从 Web 服务和批处理过程中调用。 #### 四、AWE 的应用场景 ##### 4.1 财务审批财务审批是 AWE 应用最为广泛的场景之一。例如，在处理费用报销、采购申请等时，可以通过 AWE 定义不同的审批级别和流程。 ##### 4.2 人力资源管理在 HR 管理中，员工的入职、离职、晋升等操作也需要经过相应的审批流程。AWE 可以根据职位、部门等因素自动分配审批人。 ##### 4.3 供应链管理对于供应链管理中的采购订单、库存调整等事务，AWE 可以确保每个步骤都得到正确的审批。 #### 五、AWE 的开发与配置 ##### 5.1 开发指南为了充分利用 AWE 的功能，开发者需要熟悉以下关键概念和技术： 1. **Workflow Definitions**：定义审批流程的基础单元，包括起点、终点以及中间节点的逻辑。 2. **Routing Rules**：用于确定审批路径的规则集合，可以根据不同的条件选择不同的审批人。 3. **Delegation Framework**：在特定情况下允许代理审批的功能框架。 ##### 5.2 配置过程 1. **安装与配置**：首先确保系统中已安装了 PeopleTools 8.48 或更高版本，并配置好相应的 AWE 组件。 2. **定义审批流程**：使用 PeopleSoft Application Designer 来创建和编辑 Workflow Definitions。 3. **测试与优化**：完成初步配置后，需要进行严格的测试以确保流程符合预期，并根据实际情况进行调整优化。 #### 六、AWE 的最佳实践 1. **减少修改足迹**：尽量避免对标准组件进行修改，而是利用 AWE 的灵活性来满足特定需求。 2. **文档记录**：保持良好的文档记录习惯，特别是对于复杂的审批流程，有助于后期维护和审计。 3. **培训与支持**：为最终用户提供足够的培训和支持，确保他们能够正确使用 AWE 功能。 #### 七、结论 Peoplesoft 的 AWE 为企业的审批流程提供了一个强大且灵活的解决方案。通过深入理解其工作原理、特点和应用场景，开发者可以更好地利用这一工具来提高业务效率。此外，不断积累的最佳实践也将为企业带来长期的利益。

资源推荐

资源详情

资源评论

/ PeopleSoft PeopleTools Tips & Techniques / Jim J. Marion / 493-9

Blind folio: 91

Chapter

Approval

Workflow Engine

ch03.indd 91 5/4/10 10:28:41 AM

/ PeopleSoft PeopleTools Tips & Techniques / Jim J. Marion / 493-9 / PeopleSoft PeopleTools Tips & Techniques / Jim J. Marion / 493-9



PeopleSoft PeopleTools Tips & Techniques

Chapter 3: Approval Workflow Engine



urchase requisitions, training requests, and employee transfers are some of the

many enterprise transactions that require approval. Some transactions, such as

training requests, may require a single-level manager or supervisor approval; other

transactions may use complex routing rules to determine the approval path. For

example, a purchase requisition for an item costing $10,000 or less may require no

more than a manager’s signature, whereas a purchase requisition for a single item

costing $100,000 or more may require a senior vice president’s approval. Prior to electronic

workflow systems, the approval process consisted of signed forms routed from one approver to

the next.

Prior to PeopleTools 8.48 and PeopleSoft 9.0, PeopleSoft applications used a PeopleTools

approval framework called Virtual Approver. In PeopleTools 8.48, PeopleSoft introduced the

Approval Workflow Engine (AWE). While some Financials and Supply Chain modules adopted

AWE as early as version 8.8, the 9.0 version was the first to extensively use AWE.

AWE began as a custom workflow engine for PeopleSoft’s Supply Chain Management module

in version 8.8. The Supply Chain team continued to improve the workflow engine through

release 8.9. In 9.0, many application development teams switched from Virtual Approver and

legacy workflow to the new AWE. Since AWE is now a core component of PeopleTools 8.48,

you can use it with any PeopleSoft application version.

At the time of this writing, the best available documentation for AWE is the “Approval Workflow

Engine (AWE) for HCM 9.0” and the “Delegation Framework for HCM v. 9.0” red papers available

from Oracle’s support site, http://support.oracle.com. These red papers complement this chapter.

In this chapter, you will learn how to workflow-enable transactions, reduce your modification

footprint, and use AWE from web services and batch processes.

The screenshots and navigation presented in this chapter were taken from a PeopleSoft HRMS 9.0

application. Even though AWE is a PeopleTools component that exists in every PeopleTools 8.48 and

higher PeopleSoft application, the menu navigation for AWE metadata is application-specific. In

HCM, the menu navigation for AWE is under Set Up HRMS | Common Definitions | Approvals. In

Financials, it is under Set Up Financials | Supply Chain | Common Definitions | Approvals.



Workflow-enabling a transaction is a joint effort between developers and functional experts. Once

a developer creates some supporting definitions, a functional expert can configure notifications

and complex approval rules. This contrasts with the prior PeopleTools workflow engine, which

required App Designer access to design and implement workflow activities, steps, rules, and

routings.

Workflow-enabling a transaction consists of the following tasks:

Create supporting definitions: record, SQL, and application class definitions. ■

Configure metadata. ■

Modify the source transaction. ■

In Chapter 2, we created a Web Asset component. Continuing that example, we want to add

the requirement that prior to using a web asset, a member of the Portal Administrator group must

approve the content and the web asset use case. In this chapter, we will use AWE to enhance the

Web Assets page to ensure a web asset is approved before making it available for use.

ch03.indd 92 5/4/10 10:28:42 AM

Chapter 3: Approval Workflow Engine





AWE uses queries, SQL definitions, and application classes to provide data and business logic for

routing and notifications. It also uses custom record definitions to store information about the

state of an approval.



Transactions are composed of header and detail values. A transaction encompasses all of the data

that represents a single unit. We identify a transaction through its header values. The level 0 scroll

area, for example, is a transaction’s header record. Level 1 and all the levels below it make up the

transaction’s detail records. Approving a transaction, therefore, requires approving the transaction

header.

AWE maintains approval information in its own transaction tables. The link between AWE’s

transaction tables and the main transaction table is called the cross-reference record and is defined as

containing the subrecord PTAFAW_XREF_SBR plus the transaction’s keys. The cross-reference record

is similar to the attachment repository record we used in the previous chapter, in that we create the

record and point PeopleTools to the record, but we never actually modify data within the record.

Figure 3-1 shows our new web assets cross-reference record, named APT_WA_AWE_XREF.

This will serve as the cross-reference record between web asset transactions and the corresponding

AWE transaction. Save and build the APT_WA_AWE_XREF record.

 Web assets cross-reference record

ch03.indd 93 5/4/10 10:28:42 AM



PeopleSoft PeopleTools Tips & Techniques

Chapter 3: Approval Workflow Engine





Each process has its own set of thread IDs. The AWE framework stores these thread IDs in a

record named PTAFAW_IDS. Since we created a new cross-reference record, we will need to add

a new row to the thread ID table, PTAFAW_IDS. AWE uses the thread ID as part of the cross-

reference table’s primary key. Since PeopleTools does not provide a user interface for maintaining

thread IDs, we will need to add a new thread ID value using SQL. The following SQL inserts a

new counter into the PTAFAW_IDS record:

INSERT INTO PS_PTAFAW_IDS(PTAFCOUNTERNAME, PTAFAWCOUNTER)

VALUES ('APT_WA_AWE_XREF', 1);

COMMIT

The value you provide for PTAFAWCOUNTER is the initial value to be used for thread IDs.

Consider it similar to the first check number when opening a new checking account. Once you

set the value, you can never go back and change it. For a new checking account, you might

choose to start your checks with a number like 1000, so recipients won’t question the integrity of

your checking account. With thread IDs, the starting number doesn’t matter as much. Therefore,

it seems reasonable to start thread IDs at 1. After we create our first web asset approval

transaction, the AWE framework will begin incrementing this value.



AWE triggers events throughout the approval cycle. For example, when a user submits a workflow

transaction, AWE triggers the OnProcessLaunch event. We can handle these events by creating

an event handler application class and registering the event handler with the approval process

definition.

The event handler pattern used by AWE is common to OOP. Java, for example, uses

registered event handler callbacks to notify listeners as events arise. The difference between the

AWE implementation and a Java implementation is that a Java object that triggers events may

have multiple registered listeners, whereas AWE allows only one. At the end of this chapter,

I will show you how to add this functionality with a custom event handler.

Event handlers are subclasses of PTAF_CORE:ApprovalEventHandler. The AWE

framework will call the appropriate event handler method as the event occurs during the course

of a transaction’s life cycle. Since the default handler methods do not contain any business logic,

you need to implement only the events required for your business process. The rest of the events

will be handled by the base class methods, allowing you to ignore events that are irrelevant to

your business process.



The HRMS-specific documentation recommends subclassing the

HMAF_AWE:Wrappers:ApprovalEventHandler class instead.

Other modules and PeopleSoft applications may have similar

recommendations. Consult your application-specific documentation

for additional information. Since this example is meant to apply to any

application that uses PeopleTools, it will use the base PTAF_CORE

application classes.

ch03.indd 94 5/4/10 10:28:43 AM

Chapter 3: Approval Workflow Engine



The following code listing contains declarations for the common event handler methods. For

a complete list, use App Designer to open the PTAF_CORE:ApprovalEventHandler

application class’s PeopleCode editor.

method OnProcessLaunch(&appInst As PTAF_CORE:ENGINE:AppInst);

method OnStepComplete(&stepinst As PTAF_CORE:ENGINE:StepInst);

method OnStepPushback(&userinst As PTAF_CORE:ENGINE:UserStepInst);

method OnStepReactivate(&stepinst As PTAF_CORE:ENGINE:StepInst);

method OnFinalHeaderDeny(&appinst As PTAF_CORE:ENGINE:AppInst);

method OnHeaderDeny(&userinst As PTAF_CORE:ENGINE:UserStepInst);

method OnHeaderApprove(&appinst As PTAF_CORE:ENGINE:AppInst);

Notice that each of these event handlers has some type of instance parameter. The type of

instance depends on the type of event. An approval event, for example, will receive an approval

instance. A step event, which occurs when an approval moves from one step to the next in the

approval chain, will receive an approval step instance. The instance parameter contains

properties and methods allowing you access to relevant AWE and transaction information. For

example, each of the instance classes has a thread property. The thread property corresponds to

the cross-reference record we created earlier. Since the cross-reference record contains

transaction header key values, event handlers have full access to the underlying transaction.

In our example, we will implement approve and deny handlers. These handlers will update

the status of a web asset. A web asset should not be available for use unless it is in approved

status. Since AWE maintains approval history, it isn’t necessary to maintain a transaction-specific

approved or denied flag. Nevertheless, I recommend maintaining an approval flag for

convenience. Whether you are writing reports, processes, or integration points, you may not want

to join your transactions to the AWE tables just to determine the approval state of a transaction.

The only accurate way to maintain an approval flag is through an approval event handler. In

this chapter, we will use the OnHeaderApprove and OnHeaderDeny event handler methods to

maintain the transaction record’s approval flag. This event-driven design contrasts with the legacy

workflow strategy, which involved updating the approval flag within an approval component. A

key difference between AWE and legacy workflow is that AWE does not require a component,

whereas the legacy workflow engine required a component to update workflow transactions.

Let’s create our web asset event handler. We’ll need a new application package, as discussed

in Chapter 1. Select File | New from the App Designer menu bar. When prompted for a definition

type, select Application Package. Save this new application package with the name APT_WA_AWE.

This new package will contain event handlers, user lists, criteria definitions, and many other

AWE-related application classes. After saving the new application package, add a new class

named WebAssetAppr_EventHandler. Add the following PeopleCode to this new class:

import PTAF_CORE:ApprovalEventHandler;

import PTAF_CORE:ENGINE:AppInst;

import PTAF_CORE:ENGINE:UserStepInst;

import PTAF_CORE:ENGINE:Thread;

class WebAssetAppr_EventHandler extends PTAF_CORE:ApprovalEventHandler

method OnHeaderApprove(&appinst As PTAF_CORE:ENGINE:AppInst);

method OnHeaderDeny(&userinst As PTAF_CORE:ENGINE:UserStepInst);

private

ch03.indd 95 5/4/10 10:28:43 AM

剩余49页未读，继续阅读

评论收藏

内容反馈

zhizubao

2014-08-21

好东西！虽然只有一章的内容。
yf1026000

2013-03-19

不错~~~不过要是有中文就更好了。
yangxn

2014-04-22

挺好的，就是比较简单一些了
pengpeng2277

2013-09-30

PS的人太少了，大家要多多分享。这个是英文的。还是有参考价值的
oldwolf1987

2012-06-25

受用了.. 对新手来说确实是不错的书, 请问有全本没?

前往

页

hanjian05140809

粉丝: 1
资源: 1

peoplesoft awe开发

最新资源