ISG
Member
Currently the E-Signature capture program P9500006 throws the user out of the e-sig screen if they enter an incorrect password 4 times and issues a message to the screen “The number of attempts to approve this action has been exceeded”. Unfortunately, the user can then re-select the transaction they were trying to sign for and the e-signature screen will re-appear giving the user 4 more attempts. Basically, this gives the user an infinite number of attempts.
The validation engineer sees this as a security risk and wants the user to be set to a status of “Disabled” when this e-signature failure occurs and the E-signature program to be amended to prevent users with a “Disabled” status from using the E-signature function.
My problem is determining when the failure has occurred. I have looked into the following methods:
1. Changing the E-sig program P9500006. This gets called from “under the covers” and the password validation happens there as well. I have as yet found no way of knowing what errors are displayed to the user as they are not issued directly from P9500006.
2. The program writes to the file F9500006 whenever there is a successful e-signature or when one fails after 4 attempts. Each record has a unique ID(CFRGUID) and a field SIGSUC that indicates whether the signature has failed or not (0= success and 1 = failure). I’ve tried using TER in the Before Insert and After Insert. The TK field for SIGSUC is not populated whereas other fields seem to be. Having read other posts I get the impression the TER is a bit inconsistent.
3. The F9500006 record hasn’t been written before P9500006 terminates so I can’t retrieve is there.
4. I tried accessing the F9500006 using the Unique ID in TER and had two problems. 1. When building the trigger I get the error D:\B7\PY7334\source\F9500006.c(144) : warning C4133: 'function' : incompatible types - from 'int *' to 'struct tagMATH_NUMERIC *'. Even though I used the SIGSUC data dictionary field to define the event variable. I understand that problems occur with fields defined as integers. 2. Even when I do manage to access the file F9500006 the system hangs. I can only assume there’s some file locking issues when accessing F9500006 from within it’s own trigger.
5. I created an NER function and accessed file F9500006 with the Unique ID. No record locking but I can retrieve all fields except SIGSUC. Again, I got the same error message as in (3) when I built the NER.
6. I called a UBE from the NER and was able to access SIGSUC successfully but this generates a joblog every time it’s called.
A trigger then an NER and then a UBE isn’t a great solution. I’m hoping that someone can pinpoint that I’m missing something obvious and simple to change.
We can go down the Oracle database trigger and SQL route as a last resort but would prefer something with more visibility.
Would writing the business function in ‘C’ solve the build warning error problem (unfortunately I’m not a ‘C’ coder – yet!)?
The E-sig failure message appears to be message number 182L. If I could figure out the application that presents the e-sig failure message maybe I could amend that code.
Any help in this matter would be greatly appreciated.
Thanks in anticipation,
Ian
PeopleSoft EnterpriseOne 8.0 (B7334) SP22_M1 - Oracle 9.2.0.5.0 - W2K SP4
The validation engineer sees this as a security risk and wants the user to be set to a status of “Disabled” when this e-signature failure occurs and the E-signature program to be amended to prevent users with a “Disabled” status from using the E-signature function.
My problem is determining when the failure has occurred. I have looked into the following methods:
1. Changing the E-sig program P9500006. This gets called from “under the covers” and the password validation happens there as well. I have as yet found no way of knowing what errors are displayed to the user as they are not issued directly from P9500006.
2. The program writes to the file F9500006 whenever there is a successful e-signature or when one fails after 4 attempts. Each record has a unique ID(CFRGUID) and a field SIGSUC that indicates whether the signature has failed or not (0= success and 1 = failure). I’ve tried using TER in the Before Insert and After Insert. The TK field for SIGSUC is not populated whereas other fields seem to be. Having read other posts I get the impression the TER is a bit inconsistent.
3. The F9500006 record hasn’t been written before P9500006 terminates so I can’t retrieve is there.
4. I tried accessing the F9500006 using the Unique ID in TER and had two problems. 1. When building the trigger I get the error D:\B7\PY7334\source\F9500006.c(144) : warning C4133: 'function' : incompatible types - from 'int *' to 'struct tagMATH_NUMERIC *'. Even though I used the SIGSUC data dictionary field to define the event variable. I understand that problems occur with fields defined as integers. 2. Even when I do manage to access the file F9500006 the system hangs. I can only assume there’s some file locking issues when accessing F9500006 from within it’s own trigger.
5. I created an NER function and accessed file F9500006 with the Unique ID. No record locking but I can retrieve all fields except SIGSUC. Again, I got the same error message as in (3) when I built the NER.
6. I called a UBE from the NER and was able to access SIGSUC successfully but this generates a joblog every time it’s called.
A trigger then an NER and then a UBE isn’t a great solution. I’m hoping that someone can pinpoint that I’m missing something obvious and simple to change.
We can go down the Oracle database trigger and SQL route as a last resort but would prefer something with more visibility.
Would writing the business function in ‘C’ solve the build warning error problem (unfortunately I’m not a ‘C’ coder – yet!)?
The E-sig failure message appears to be message number 182L. If I could figure out the application that presents the e-sig failure message maybe I could amend that code.
Any help in this matter would be greatly appreciated.
Thanks in anticipation,
Ian
PeopleSoft EnterpriseOne 8.0 (B7334) SP22_M1 - Oracle 9.2.0.5.0 - W2K SP4
