Refer to GPII wiki and GPII Architecture Dashboard to understand what the GPII is.
The GPII core personalisation architecture is held in the GPII universal repository.
This repository collects payloads that flow among GPII modules. Refer to the diagram below for the GPII modules as well as the personalization work flow in shared/public workstations.
Each module is mapped to at least one file.
The file name convention is: [Cloud|Local]ModuleName[-Functionality].md
.
For example, the payload file for the context manager that is deployed on the local machine to perform the functionality of evaluating match is named as LocalContextManager-EvaluateMatch.md
.
These files contain the input payload (or request) that triggers the module to start, as well as the output payload, if any, that the module returns or passes to the next module.
The payloads in this repository cover 3 typical processes that are supported by the GPII deployment for public workstations, shown in the diagram above. These processes are representative but not exhaustive. That said, the payloads collected in this repository do not cover all payloads that flow through GPII.
The 3 processes covered in this repository are:
The following is the trace of requests and payloads when a user keys into GPII:
- Device Reporter
- Cloud Based Flow Manager in Untrusted Settings
- Preferences Server
- Solutions Registry
- Cloud Based Match Maker
- OAuth Server
- Cloud Based Context Manager
- Cloud Based Transformer
- Life Cycle Manager
- Settings Handler
- Lifecycle Handlers
The following is the trace of payloads when a user keys out of GPII:
The following is the trace of payloads when a context change is detected within GPII: