Tuesday, April 26, 2011

Prompt Values specified on Add Mode Search Record is not enforced when using ExcelToCI

If you are creating Component interface by default it will not enforce the prompt values specified on Add search record and will let you input any values even though they are not valid. This is an issue when inserting new rows using ExcelToCI as it allows the user to enter invalid values without giving any error message.

To avoid this issue, open up the Add mode Search record for the component and go to Record field properties for the search fields and check Search Edit check box.  This will enforce the use of valid values when adding a new row using Component interface used in ExcelToCI. By default Search Edit is not checked. 

Here is the description of this field in PeopleBooks.

Search Edit    Enabled only if Search Key is selected. Selecting this option enforces the required property and table edits on the search page. It also enforces these edits under circumstances where the search page would normally be bypassed. With this option, the user no longer has the ability to perform partial searches on this field.

Here is the MOS (My Oracle Support) Link that documents this issue.

E-CI: Component Interface Does Not Validate Record Edits (Against Prompt table) When Using Create [ID 664377.1]

Does Row Level Security Work in ExcelToCI? (Doc ID 972241.1)

As per the above resolution, row level security is not enforced using ExcelToCI.

Thursday, April 21, 2011

Integration Gateway: General Connection Failed (158,10836)

We send a XML Message to Vertex using HTTPTargetConnector  in an app engine program in batch mode.
Occasionally we see that the Return response is the following : Integration Gateway: General Connection Failed (158,10836)

On seeing some other resolution the following could be the cause of this message.
This error is thrown when there is no valid response.

Possible errors include:
Bad gateway URL
Sync Service Timeout set and Service actually timed out.
Java exception thrown - Check Application Server for possible Java exception.
Since URL is correct and there is no Java exception, I think the reason is Sync Service Timeout set and Service actually timed out.

When I was reading PeopleBooks for HTTPTargetConnector Properties there is a Header Property called Timeout for which the default value is 50 seconds.

Here is the explanation from the peoplebook.
Specify the time in milliseconds for the connector to wait for the message to transmit. If the timeout period expires without a successful transmission, the transaction fails.
The default value is 50000 (50 seconds).

 

Setting the property value to 120000 (120 seconds or 2 minutes), resolved the issue. Make sure that you modify the Node Connector as well as routing connector properties if one is defined.

 

image

Navigation : PeopleTools –> Integration Broker –> Integration Setup –> Nodes –> Connectors

Property ID: HEADER

Property Name: TimeOut

Value: 120000

Go to Routings Tab and Select the Outbound Routing and Select Connector Properties. If you have a Property defined  for e.g. PRIMARYURL then you will need to add it here as well, otherwise if it is blank then it is not needed to be added here.

Thursday, April 07, 2011

Application Engine Program : PSPAL::Abort: Unexpected signal received

When we create a Application engine program which refers to an State record, and migrate it to other environment without migrating the State record, it gets migrated successfully. Trying to run this program on the Batch Server gives the following error message.

Record XYZ not defined (108,505)
1341: 1301685557: PSPAL::Abort: Unexpected signal received
1341: 1301685557: PSPAL::Abort: Location: /vob/peopletools/src/pspal/exception_sigaction.cpp:492: RecoverableSignalHandler
1341: 1301685557: PSPAL::Abort: Generating process state report to /xxx/xxx/scripts/LOGS/psae.1341/process_state.txt
1341: 1301685557: PSPAL::Abort: Terminating process now.

in Windows
2564: 1301686035: PSPAL::Abort: Unrecoverable exception received
2564: 1301686035: PSPAL::Abort: Location: E:\pt85010b-retail\peopletools\SRC\pspal\exception_winunhandled.cpp:577: PSPAL::UnhandledExceptionFilter::RecoverableExceptionFilter
2564: 1301686035: PSPAL::Abort: Abort diagnostics generation is currently disabled
2564: 1301686035: PSPAL::Abort: Terminating process now.
PeopleTools 8.50.10 - Application Engine
Copyright (c) 1988-2011 PeopleSoft, Inc.
All Rights Reserved

Record XYZ not defined (108,505)
Message Set Number: 108
Message Number: 505
Message Reason: Record XYZ not defined (108,505)

Workaround
Copy the missing AET Record to the target database and it application engine program will work fine.

ExcelToCI Error occurred in routine sendSOAPRequest_SubmitToDB: The operation timed out.

When trying to upload about 7000 rows using ExcelToCI for a custom component, users are getting the following error.

Error occurred in routine sendSOAPRequest_SubmitToDB:
Error:
Number: -2147012894
Description: The operation timed out

After doing my investigation, checking the web server and appserver access log I found the following issues, and here is what i did to resolve the issue. This is not documented anywhere. Please create a resolution if possible to help others.

1. Found that ExcelToCI uses SERVERXMLHTTP MSXML 6.0 object to send the SOAP request to the webserver,
   Set xHTTP = CreateObject("MSXML2.SERVERXMLHTTP.6.0")
   This request has a default 30 second timeout for receiving a packet of response data from the target server,
   See link : http://msdn.microsoft.com/en-us/library/ms760403 for more details on timeouts.

2. After checking the webserver access log (PIA_Access.log), determined that some of the POST request are taking about 59 seconds to complete and therefore we were receiving the error.

To resolve this issue, change the VB Macro code in ExcelToCI spreadsheet as follows

=======================================================

Add this line before xHTTP.send xDoc.xml in StagingAndSubmission Module under function sendSOAPRequest_SubmitToDB
Dim lResolve, lConnect, lSend, lReceive As Long
lResolve = 60 * CLng(1000)
lConnect = 90 * CLng(1000)
lSend = 90 * CLng(1000)
lReceive = 120 * CLng(1000)

xHTTP.setTimeouts lResolve, lConnect, lSend, lReceive
=======================================================

After changing this value, the ExcelToCI was still failing. Once again I checked the web Server and App server log and found that after loading about 50 to 60 rows, request is taking more than 5 minutes to respond and appserver is killing the appserv thread and therefore error was received saying that The Operation time out.

I had two options
1. Increase the XMLHTTP timeout and also increase the appserver timeout or find out why a request is taking more than 5 minutes to complete. Used Precise i3 performance monitoring tool and also the live Oracle
session and determined the following issue.
1. CI was firing sql to fetch location code description using a view that was not correctly joined with other large table using location code.
2. A Save Edit Peoplecode was written at Level 2 to fetch some data from the Oracle table using SQL Exec. This was causing this sql to fire 160,000 times as it was firing for every row in the scroll as new rows are being added.

Following improved the performance.
1.  Remove the related display field from the page. Alternative option is to tune the sql for related display field.
2.  Moved the save edit code to field edit, so that it fires only for the newly inserted rows. Other option is to write conditional logic to see if row is changed.

After these, 2 changes, the process finished inserting 7100 rows in 23 minutes. Only two request exceeded  default timeout. One took 32 and other 35 seconds to respond.

I have also noticed, that if Chunking factor is reduced to 1 to have smaller number of rows processed, PSAPPSRV is restarting due to recycle count of 5000 being reached, and this results in a login Error and HTML (invalid XML) data is being sent to the Excel. Is this the expected behavior?  Only solution to this issue is to increase the recycle count temporarily and change it back to original. Fortunately this parameter is dynamic and does not require restart of the appserver.