Employee profile retrieval¶
This operation builds a clsEmployeeData object for one person. The implementation prefers the current security principal when the caller supplies a mail ID, falls back to ADP or virtual-employee rows, and only uses the WCIS fallback when a user-based lookup still has no ADP match.
| Field | Value |
|---|---|
| Operation ID | OP-SB-01 |
| Trigger | Caller invokes GetDataByMailID, GetDataByEmployeeID, or a lazy employee adjunct property. |
| Inputs | User ID, employee ID, bypass-security-principal flag, include-virtual flag |
| Outputs | Hydrated clsEmployeeData instance |
| Primary components | clsEmployeeData.GetDataByMailID, clsEmployeeData.GetDataByEmployeeID, clsEmployeeData.Criteria.BeforeRetrieve, clsEmployeeData.Criteria.ProcessRequests |
| Entry point | Business\SAIF.Business\clsEmployeeData.vb |
Steps¶
- The caller chooses the single-record factory that matches the available identifier, then creates criteria with either a user ID or an employee ID and optionally turns on virtual-employee support (SQL-023, VIRTUAL_EMPLOYEE).
BeforeRetrieveprepares up to three requests in priority order: a security-principal request when the caller passed a user ID and did not bypass principal lookup, an ADP request that targetsUSER_IDorEMPLID, and a WCIS request reserved for the user-ID fallback path (SQL-023, SQL-024, ADP_EMPLOYEE, WCIS_EMPLOYEE).- When the security-principal request succeeds, the object is filled directly from
clsAccountMaintProxy.GetUserInfo, including name, mail ID, phone, and department metadata, and the database requests are skipped. - If the principal lookup returns no full name, the code clears the provisional result and continues into the ADP/WCIS retrieval path.
- The ADP request executes the single-employee SQL and optionally unions
VIRTUAL_EMPLOYEErows when the criteria allows virtual records (SQL-023, ADP_EMPLOYEE, VIRTUAL_EMPLOYEE). ProcessRequestsreads the first ADP row, populates identity, phone, email, department, title, active flag, supervisor, and desk-location fields, and keeps the result as the authoritative employee profile (SQL-023, ADP_EMPLOYEE).- If the ADP request returned no row and the original lookup came from a user ID,
ProcessRequestsexecutes the WCIS fallback SQL and fills the object from WCIS name fields plus a synthesized@saif.comemail address (SQL-024, WCIS_EMPLOYEE). - When the caller starts from an employee ID instead of a user ID, the WCIS branch is not attempted.
- Lazy adjunct accessors use smaller follow-up lookups for details that are not always loaded with the base profile, including desk location and mobile phone (SQL-025, ADP_EMPLOYEE, ADP_EMPLOYEE_PHONE_VIEW).
- The resulting object is returned to the caller, with helper methods such as
Exists,CanLeaveMessage, andPhoneByTypeoperating only on the fields hydrated by the earlier branches.
Process flow¶
The following diagram visualizes this operation's control flow.
flowchart TD
Start([Employee lookup request]) --> Build[Build employee criteria]
Build --> Principal{User ID and principal lookup enabled?}
Principal -->|Yes| PrincipalLoad[Try security-principal user info]
Principal -->|No| ADP[Query ADP or virtual employee]
PrincipalLoad --> Found{Principal row usable?}
Found -->|Yes| Return1([Return employee])
Found -->|No| ADP
ADP --> ADPFound{ADP row found?}
ADPFound -->|Yes| Return2([Return employee])
ADPFound -->|No| WCIS{Lookup started from user ID?}
WCIS -->|Yes| WCISLoad[Query WCIS fallback]
WCIS -->|No| Empty([Return empty object])
WCISLoad --> Return3([Return fallback employee])
Failure and edge-case behavior¶
- User-ID lookups that miss both the security principal and ADP can still succeed through the WCIS fallback, but employee-ID lookups do not take that path.
- Virtual-employee rows are only included when the factory or property explicitly enables
includeVirtualEmployee. - Desk-location and mobile-phone accessors depend on follow-up SQL calls and return empty values when the adjunct rows are absent.
Related documentation¶
Sources¶
Business\SAIF.Business\clsEmployeeData.vb