As a Peoplesoft developer (working with Peopletools-release 8.47.08), I have spent quite some time resolving issues caused by unexpected database-commits. As far a I know there’s no overall topic on this in Peoplebooks, therefore I will share my experience via this blog.

1) Database-updates via DML in a SQLExec-statement (e.g. INSERT INTO PS_TEST_TABLE VALUES(‘value_field_1′,’value_field_2′), triggered via an online component:
Peoplebooks states that DML in a SQLExec-statement is only allowed in FieldChange, SavePreChange, Workflow and SavePostChange events.
There’s a big difference in the outcome per event though; when this statement is put in a FieldChange-event, the DML is committed instantly, and this is something you probably don’t want!

2) Database-updates via DML in a SQLExec-statement (e.g. INSERT INTO PS_TEST_TABLE VALUES(‘value_field_1′,’value_field_2′), triggered via an Application Engine:
These updates are being committed according the AppEngine’s commit-settings.

2) Database-updates via a component interface, triggered via an online component (e.g. component A triggers component interface B_CI, triggering component B):
These updates are being committed as soon as the CI save-method is being invoked from the calling component (e.g. component A).

3) Database-updates via a component interface, triggered via an Application Engine (eg. AppEngine AE_1 triggers component interface B_CI, triggering component B):
These updates are being committed according the AppEngine’s commit-settings.
An exception to this rule I just recently encountered: the GetFile-statement leads to an immediate commit, even when used in an AppEngine-context!

Until now I was used to installing PeopleSoft on SQLServer 2005/2008 or Oracle 9i/10g. For this particular installation, PeopleTools 8.51 on a Unicode Oracle 11g database, I ran into two issues I never ran into before. Luckily fixes were easy, but finding a solution usually takes a lot of time.

Recently we had to make quite some customizations in Vanilla PeopleCode in the ePerformance module of HCM. In this case we decided to use an Application Package. We decided to put all our code for the modifications in a class. This worked out quite elegant.
We created a component object in the PostBuild PeopleCode of the Component.

Example:

    import KP_EP_FUNCTIONS:BonusSheetCalc;

    &oBonusSheetCalc = create KP_EP_FUNCTIONS:BonusSheetCalc(&sBonusStat);

In the private section we could put all the variables, which we would put normally as component variables. Example:

   private

   instance boolean &bBnsMtxChg;
   instance boolean &bEditStat;
   instance Rowset &rsBnsShtTgtDpt;

Then at every piece of PeopleCode where we need to use one of the methods, we only needed to put the declaration of the component object and all the defined methods and variables are then available:

   Component object &oBonusSheetCalc;
   &oBonusSheetCalc.SavePreChange(EP_APPR.PERIOD_BEGIN_DT, &PushButton);

There is a disadvantage though. If you are working in a project with several people, then only person can work on the Application Package at a time.

The Release Value Proposition for PeopleTools 8.52 has been posted on metalink.

This realese of PeopleTools introduces and extends current PeopleTools technology that look and behave more and more like Fusion Applications. With this version the transition or fusion of PeopleSoft customers to Fusion Applications will be more streamlined.

In this post I will highlight some of the new features of PeopleTools 8.52

With the release of PeopleTools 8.50, Related Content was introduced. Related Content Framework enables you to contextually link PeopleSoft pages to other PeopleSoft pages and non-PeopleSoft pages and view all related pages within one frame, without leaving the primary page.

This post describes the steps that need to be taken to enables Portal Related Content Services in PeopleSoft Applications.