This document describes how a developers and designers should work with implementations of new Security Checkpoints.
Security Checkpoints: each checkpoint has an identifier "Checkpoint Id", a description, and a message.
All "Checkpoint Id" should be prefixed by DOMAIN. In most cases, DOMAIN is the IFS component in which the checkpoint resides, such as SINWOF or DOCMAN.
Possible exceptions: Exceptions are not recommended, stick to the basic rule if possible! But it may be necessary to have a broader domain such as GENERAL or SECURITY, if implementing one security checkpoint which is supposed to affect several components.
The "Checkpoint Id" suffix should be a short but reasonably understandable English name of the functionality affected by the checkpoint. Abbreviations are allowed. Examples of suffixes are _INVOICE_AUTHORIZING, _APPROVE_STEP etc etc which within their specified DOMAIN are unique and easy to comprehend what they do.
This field is a humanly readable description of the checkpoint does. The description exists mainly to help system configuration technicians setup Security Checkpoints, so the description should be written to be understandable by a system technician or application consultant with limited or no understanding of development specifics.
It is a good idea to have the most important information early in the description. This helps system configuration technicians as the information often is viewed as a list with just a small part of the description shown.
The primary purpose of the message is to provide useful information to system administrators who are managing the Security Checkpoint log.
It is possible to include parameters from the PL/SQL application logic into the message. This is including &PARAMETER in the message text, which will insert the parameter named PARAMETER. Please do use this functionality to add important information to the log, for example invoice numbers, document numbers, customer number or whatever information is important to accurately document what business information was modified when the checkpoint was passed.
A rather good example of a message is "Person &PERSON_ID
approved Document Revision &DOC_CLASS-&DOC_NO-&DOC_SHEET-&DOC_REV".
The message explains what has occurred (a document was "approved")
and what business object (in this case, a document revision
identified by &DOC_CLASS-&DOC_NO-&DOC_SHEET-&DOC_REV)
was affected. So, an
administrator reading the log will easily understand it!
Tips! Avoid including text such as ”checkpoint”, ”gate”, ”authentication”, ”password” etc in the message, as it is redundant text which is common for every single security checkpoint. Also avoid including the Foundation1 username or the transaction date; this information is always added to each log entry.
An Application / Business Analyst should determine where a security checkpoint is needed business wise. Designers are encourage to specify where in the code the changes should be implemented, as it may not always be trivial to determine.
The code added into PL/SQL to call a security checkpoint is pretty straight forward. Fist, create a message of type 'SECURITY_CHECKPOINT'. Add parameters to the message, to enable the design of good log entries. Finally, call Security_Sys.Security_Checkpoint with the name of the checkpoint and the 'SECURITY_CHECKPOINT' message.
DECLARE
Gate_Msg_ VARCHAR2(2000);
BEGIN
Gate_Msg_ := Message_Sys.Construct('SECURITY_CHECKPOINT');
Message_Sys.Set_Attribute(Gate_Msg_, 'PERSON_ID', Person_Info_Api.Get_Id_For_User(Fnd_Session_API.Get_Fnd_User));
Message_Sys.Set_Attribute(Gate_Msg_, 'DOC_CLASS', rec_.doc_class);
Message_Sys.Set_Attribute(Gate_Msg_, 'DOC_NO', rec_.doc_no);
Message_Sys.Set_Attribute(Gate_Msg_, 'DOC_SHEET', rec_.doc_sheet);
Message_Sys.Set_Attribute(Gate_Msg_, 'DOC_REV', rec_.doc_rev);
Security_Sys.Security_Checkpoint('DOCMAN_DOC_REV_SET_TO_APPROVED', Gate_Msg_);
END;
Registering a security checkpoint includes defining the default Description, default Message and specifying which Parameters are allowed. Example bellow:
-----------------------------------------------------------------------------
-- Registering Security Checkpoints
-----------------------------------------------------------------------------
PROMPT =======> Registering Security Checkpoint Gate "DOCMAN_DOC_REV_SET_TO_APPROVED"
DECLARE
Gate_Id_ VARCHAR2(1000) := 'DOCMAN_DOC_REV_SET_TO_APPROVED';
Info_Msg_ VARCHAR2(32000) := '';
Par_Msg_ VARCHAR2(32000) := '';
BEGIN
-- Construct Main Message
Info_Msg_ := Message_Sys.Construct('GATE');
Message_Sys.Add_Attribute(Info_Msg_, 'DESCRIPTION', 'Used when approving a Document Revision');
Message_Sys.Add_Attribute(Info_Msg_, 'MESSAGE', 'Person &PERSON_ID approved Document Revision &DOC_CLASS-&DOC_NO-&DOC_SHEET-&DOC_REV');
Message_Sys.Add_Attribute(Info_Msg_, 'ACTIVE_DB', 'TRUE');
-- Adding parameters
-- Construct Parameter Message
Par_Msg_ := Message_Sys.Construct('PARAMETERS');
Message_Sys.Add_Attribute(Par_Msg_, 'FNDUSER', 'STRING');
Message_Sys.Add_Attribute(Par_Msg_, 'PERSON_ID', 'STRING');
Message_Sys.Add_Attribute(Par_Msg_, 'DOC_CLASS', 'STRING');
Message_Sys.Add_Attribute(Par_Msg_, 'DOC_NO', 'STRING');
Message_Sys.Add_Attribute(Par_Msg_, 'DOC_SHEET', 'STRING');
Message_Sys.Add_Attribute(Par_Msg_, 'DOC_REV', 'STRING');
-- Add Parameters message to main message
Message_Sys.Add_Attribute(Info_Msg_, 'PARAMETERS', Par_Msg_);
-- Register Security Checkpoint Gate
Sec_Checkpoint_Gate_Api.Register(Gate_Id_, Info_Msg_);
END;Please read Security Checkpoint – Web Client considerations if implementing a Security Checkpoint which will affect IFS Web Client functionality. Because a web interface is less "controlled" than a thick client, there are some limitations with the web implementation. You as a developer must adapt to these limitations when developing a security checkpoint which will affect IFS Web Client.