Fluid and Search Pages

According to the 'Fluid Programming Fundamentals Red Paper', there are three types of search alternatives:

1. Real Time Search
   This uses a Pivot Grid with the Component as the source, and the Pivot Grid Wizard will create a query in the background using the search record.
   
   To enable this, on the Internet tab the Search Page section should be 'Search', and on the Fluid tab the Search Type should be 'Standard'.


2. Keyword Search
   This uses a Search Index.
   
   To enable this, on the Internet tab the Search Page section should be 'Keyword', and on the Fluid tab the Search Type should be 'Standard'.


3. Search Page
   This is a custom implementation of the PTS_NUI_SEARCH or PTS_NUI_SEARCH_S Fluid 'Search' pages.
   
   This would be custom page development, and you would insert the page into the component.

Also under Search Type (on the Fluid tab) there is the option for 'None' and 'Master/Detail'.
You can see these options under PSPNLGRPDEFN.INCSEARCH:

• 0 = None. This seems to be the default , and the vast majority of components have this.
• 1 = Standard. 
• 2 = Master/Detail. In the FSCM and HCM databases I haven't seen any of these.

The main difference between 1 and 2 seems to be that 1 -> PTS_NUI_SEARCH as the Search Page, and 2 -> PTS_NUI_SEARCH_S as the search page. I didn't notice any difference in the search between the two when using the Pivot Grid search. Although you can see in the HTML references to the search page, so you can see which one you are on.

For the Master/Detail implementation, there is also the option of using the PT_MDSTARTPAGE_NUI component. With this you define the Portal CREF pointing to this, and add additional parameters like so:

nRow=0&GMenu=FSU_DB_PRIVS&GComp=MY_COMPONENT&GPage=MYPAGE

This component must also be a Fluid component, with Search Page Type of 'None'. The page will be a 'Standard' Fluid page.

The page will have at least two 'Layout Only' groupboxes with the outer one having the following styles:

psc_scroll psa_md_grouplet

Inside the inner groupbox there should be a grid with at least the following fields.

• A 'Layout Only' groupbox with PTLAYOUT.GROUPBOX1, with the style 

  ps_vtab

• A hyperlink which will be used to contain the link.
• (Optionally) an edit box used for the counter, with the style 

  psc_list_count

You would then write some PeopleCode on Page Activate (or Component Postbuild perhaps) which will populate the grid with the links you want to add.

Then on the groupbox field you need to set the following properties:

SetGroupletActionUrl
SetGroupletDisplayIn
IsGroupletLabelOnly
Visible

For example:

&sMenu = MenuName.MY_MENU;
&sComp = Component.MY_TARGET_CMP;
&sPage = Page.MY_TARGET_PG;
&sNewURL = GenerateComponentContentURL(%Portal, %Node, @("MenuName." | &sMenu), %Market, @("Component." | &sComp), @("Page." | &sPage), %Action_UpdateDisplay);
&sNewURL = EncodeURL(&sNewURL | "&SEARCH_KEY=" | &SearchKeyValue); /* If necessary */
&rs(&n).PTLAYOUT.GROUPBOX1.SetGroupletActionUrl(&sNewURL);
&rs(&n).PTLAYOUT.GROUPBOX1.SetGroupletDisplayIn(%GroupletActionMDTargetFluid);
&rs(&n).PTLAYOUT.GROUPBOX1.IsGroupletLabelOnly = True;
&rs(&n).PTLAYOUT.GROUPBOX1.Visible = False;
&rs(&n).MY_RECORD.LINE_NBR.Value = &nRow;
&rs(&n).MY_RECORD.LINE_NBR.Label = &Value;
&rs(&n).MY_RECORD.LINE_NBR.LabelImage = @("Image.CHECKLIST_64");
&rs(&n).MY_RECORD.COUNTER.Value = &NumOfRows;

Note: You can see this in detail under the 'Implementing Master/Detail Components' section in PeopleBooks 'Working with Master/Detail Components'.

Way to use Java to grab classpath

Easy to combine with the IScript from before.

Function Test_Java_Path();
   %Response.SetContentType("text/plain");
   %Response.WriteLine("");
   %Response.WriteLine("------ Java -------");
   Local JavaObject &sys = GetJavaClass("java.lang.System");
   Local string &cp = &sys.getProperty("java.class.path");
   Local array of string &tokens = Split(&cp, &sys.getProperty("path.separator"));
   For &i = 1 To &tokens.Len
      Local string &token = Lower(&tokens [&i]);
      %Response.WriteLine("&token:  " | Lower(&tokens [&i]));
   End-For;
End-Function;

Page and Field Configurator

I had a requirement to disable all of the fields on a run control page, and to populate two of the run control fields with values.

I thought that this would be a good opportunity to test the Page and Field Configurator.

As there were a dozen or so fields, I tried at first to use the 'Configure Page Visibility' grid, as you can make the page Display Only. But the problem with this was that the run control links and the 'Run' button were also disabled (as they didn't have the options set to be enabled when display only).

Instead I used the 'Configure Field Properties' grid and selected the fields from the lookup (a modal component) and selected the 'Disable Entry' option.

However, I noticed that the Pay Cycle field which was a series of radio buttons, was not available to select. From memory, the PeopleCode is querying the PSPNLFIELD table but skipping the Radio Button fields.

To get around this I was able manually insert the value into the database, e.g.

INSERT INTO PS_EOCC_CONFIG_FLD (PNLGRPNAME,MARKET,SEQUENCE_NBR,RECNAME,FIELDNAME,OCCURSLEVEL,RECNAME1,FIELDNAME1,LBLTEXT,PNLNAME,STDPNLNAME,PTCS_PNLFLDNAME,EOCC_LBL_OVERRIDE,EOCC_IS_REQUIRED,EOCC_DFLT_VALUE,EOCC_VISIBLE_FLAG,EOCC_DISABLED,FIELDTYPE,FIELDUSE,EOCC_FIELD_TYPE,EOCC_SBP_LEVEL,RECNAME_BASE,PTAI_SYSTEM_DATA) 
VALUES (...)

The 'Map to Portal Registry' page allows you to automatically create the Event Mapping using the EOCC% services.

So this catered for the first part of the requirement, and to cater for the second part of the requirement I was able to create another Event Mapping PeopleCode which sets the value of the two fields. I was able to configure this to run PostBuild after the EOCC_POSTBUILD service.

So there were no customizations to the delivered objects!

This was migrated by using the Data Migration Workbench and an Application Designer project.

• The Application Designer project contained the Application Packages, and the PeopleCode.
• The DMW project contained data sets EOCC_CONFIGURATION, RCF_SERVICES, and RCF_SERVICE_DEFINITIONS.

IScript for testing PeopleCode

When your Application Package PeopleCode doesn't have any Component Buffer references, then creating an IScript (and registering it to a portal CREF) allows you to test your Application Package PeopleCode.

Function Disable_Tracing();
   SetTraceSQL(0);
   SetTracePC(0);
   
End-Function;

Function Enable_Tracing();
   SetTraceSQL(31);
   SetTracePC(2060);
   
End-Function;

Function Test_ConfigureClassicPlusComponent();
   Enable_Tracing();
   %Response.SetContentType("text/plain");
   %Response.WriteLine("Turn Off");
   %Response.WriteLine("COMPONENT: " | String(ConfigureClassicPlusComponent(Component.COMPONENT, "GBL", 0)));
   Disable_Tracing();
End-Function;

rem Register this to the CREF and to a Permission List;
Function IScript_Test();
   rem Test_Environment_Variables();
   rem Test_ConfigureClassicPlusComponent();
End-Function;

I find it especially useful when testing for Web Services PeopleCode, as it allows you to build out the logic before testing the Service Operation itself.

The URL Type will be 'PeopleSoft Script', which will give you the fields to enter the Record Name (e.g. WEBLIB_ACC_TEST), Field Name (e.g. ISCRIPT1), PeopleCode Event Name (e.g. FieldFormua), and the PeopleCode Function Name (e.g. IScript_Test).