Pipeline types
The pipeline type is directly related to the type of events a pipeline emits. There are two different types of pipelines a developer can instantiate:- Telemetry Event Pipeline: Can only emit Telemetry Events and uses Write Telemetry Events REST API.
- PlayStream Event Pipeline: Can only emit PlayStream Events and uses Write Events REST API.
Auth types
Another important piece of the pipeline creation is the auth type. There are two supported auth mechanisms for PlayFab Events—Entity auth and Telemetry Key auth. Entity auth is used when the game developer wants to link their events against a particular entity for further aggregation or analysis. For example, the game developer could log events related to player’s actions to do further behavior analysis of your title players that allow for segmentation. Telemetry Key auth is used when the game developer wants to log events that don’t necessarily need to be linked to an entity. For example, prior to having a logged in player, the title can start sending events related to performance or specific metrics it would like to collect for further analysis. This can be done without the need of going through the regular entity authentication process. Supported auth type / Event type combinationsEntity auth
This auth type is the normal and most common PlayFab Authentication method. It’s tightly related to a specific entity and it requires you to call the corresponding PlayFab Login APIs in order to get an Entity Token to be used on any subsequent calls. The following list represents the different type of entities that can be used with Entity Authentication.- namespace: The namespace entity represents the cross-title player identity and shared-data scope. The Publisher ID identifies the namespace.
- title: The title entity represents the global information scoped to that title.
- master_player_account: The
master_player_accountis a player entity shared by all titles in a namespace. - title_player_account: For most developers, title_player_account represents the player in the most traditional way.
- character: The character entity is a subentity of title_player_account.
- group: The group entity is a container for other entities. It’s currently limited to players and characters.
Telemetry key auth
Telemetry Key authentication doesn’t require an Entity Token, therefore it isn’t tied to any specific entity. If Telemetry Key auth is used, a PFEventPipelineTelemetryKeyConfig struct is required during pipeline creation. There are two main pieces of this struct:- A Telemetry Key that consists of a string that is created and managed via PlayFab Game Manager.
- A PFServiceConfigHandle that lets the SDK know which is the right service configuration that should be used for uploading the events. The service config handle is created during SDK Initialization by calling PFServiceConfigCreateHandle.
Event Pipeline configuration
As previously mentioned, the event pipeline has some configurable properties that can be provided after pipeline creation through the PFEventPipelineConfig struct parameter. The configurable properties are:- maxEventsPerBatch: The maximum number events that are batched before writing them to PlayFab.
- maxWaitTimeInSeconds: The maximum time the pipeline waits before sending out an incomplete batch.
- pollDelayInMs: How long the pipeline will wait to read from the event buffer again after emptying it.
- compressionLevel: Defines the compression level that is used on the compression algorithm. For more details about compression, see GZIP Compression.
- retryOnDisconnect: The event pipeline will retry sending events that failed due to lost connection. Only available for Telemetry Event Pipeline.
- bufferSize: The limit of the amount of events in the pipeline’s buffer.
Default values
In the case where PFEventPipelineConfig has only some properties specified, the ones being empty are overwritten and use the default values.
For an example of how any of these properties can be updated for the event pipeline see Update Pipeline Configuration.
GZIP Compression
The Event Pipeline provides an option of compressing body payloads using GZIP Compression standard. The desired compression level can be specified inside the PFEventPipelineConfig struct that is part of the PFEventPipelineUpdateConfiguration API parameters. A lower compression level achieves less compression but has the highest speed and a higher compression level achieves better compression rates but has the slowest compression speed. The difference in compression rates is all dependent on the type of data being sent. Depending on the size and randomness of the data, compression rates can be the same even on different levels. Trade-Offs: Using compression increases CPU Time due to the added complexity of running a compression algorithm but, on the other hand, network body payload is dramatically decreased. So, depending on the game needs and resources, it’s up to the game developer if compression should be used. Based on internal validation, there’s an average of 20% increase in CPU Time and an average of 91% decrease in Payload Body Size. These percentages could largely vary depending on the payload size and complexity of the data being compressed.Event handlers
As part of pipeline creation, game developers can provide two optional event handlers that are invoked when events are uploaded. However, if the game developer wants a “fire and forget” experience, can omit providing the event handlers. The event handlers that can be provided are as follows:- PFEventPipelineBatchUploadSucceededEventHandler: As the name suggests, it receives all the events that are successfully uploaded to PlayFab.
- PFEventPipelineBatchUploadFailedEventHandler: It will receive all the failed events after going through the pipeline retry logic.
Pipeline creation examples
Below you can find different examples on how to instantiate an event pipeline based on the topics discussed previously.-
Telemetry Event Pipeline creation with Entity auth
If the developer wants to send Telemetry Events and doesn’t have the need of using Telemetry Key auth, the PFEventPipelineCreateTelemetryPipelineHandleWithEntity API serves for this purpose as seen in the next example:
This example shows how to create a Telemetry Event Pipeline that uses Entity authentication and it has no handlers. This means the pipeline fires the events and forgets about the result.
-
Telemetry Event Pipeline creation with Telemetry Key auth
If the developer wants to send Telemetry Events and has the need of using Telemetry Key auth, the PFEventPipelineCreateTelemetryPipelineHandleWithKey API serves this purpose as seen in the next example:
This example shows how to create a telemetry event pipeline that isn’t using Entity Auth. The event pipeline starts uploading events using the Telemetry Key with the possibility of adding an Entity later on. See Switching to Entity Auth or Updating Entity
-
PlayStream Event Pipeline creation
If the developer wants to send PlayStream Events, the PFEventPipelineCreatePlayStreamPipelineHandle API serves this purpose as seen in the next example:
This example shows how a PlayStream Event Pipeline is created that uses Entity authentication and it has no handlers. Which means that the pipeline fires the events and forgets about the result.
-
Event Pipeline using event handlers
This example shows how event handlers would be provided to the Pipeline creation APIs.
Emitting events
Emitting events is a straightforward operation once the event pipeline is already created. The game developer should call PFEventPipelineEmitEvent API that receives the existing event pipeline handle and the event they want to send.E_PF_API_CLIENT_REQUEST_RATE_LIMIT_EXCEEDED (0x892354dd)
Switching to Entity auth or updating Entity
If a pipeline was created using only a Telemetry Key configuration, there’s a way to switch to Entity authentication or if you want to update your pipeline to use a different Entity. By using the PFEventPipelineAddUploadingEntity, it’s possible to attach an entity to a running pipeline without the need of reinitialize it. It also replaces the existing entity, if any. Example: A Telemetry Event Pipeline is created with Telemetry Key configuration at the beginning of title execution. Possible reasons for this are that there isn’t a player identity yet or simply we don’t want to log anything related to a player still.Switching to Telemetry Key auth
Expanding on the previous scenario, if the developer wants to go back to Telemetry Auth and detach the event logging from the entity they can call PFEventPipelineRemoveUploadingEntity and pass the event pipeline handle like this:Update Pipeline configuration
Pipelines can be easily updated using the PFEventPipelineUpdateConfiguration API, which receives the existing event pipeline handle and a new configuration struct as follows:Invalid / deactivated Telemetry keys
In case a Telemetry key is deactivated or if an invalid key is provided at pipeline creation, any Event Pipelines running using that Telemetry Key will start failing as soon as they find out the key is invalid or deactivated. In the eventual case where the customer reactivates the key, the pipeline won’t realize about that and will keep sending failures back through the failed event handler. It’s worth mentioning that this behavior is session-based, which means that if the title is restarted, a new pipeline is created and will be able to upload events again.Pipeline handle lifecycle
Like other PlayFab handles, event pipeline handles use a duplicate/close pattern:- PFEventPipelineCloseHandle: Closes a pipeline handle. When the last handle to a pipeline is closed, the pipeline is destroyed and any remaining buffered events are flushed.
- PFEventPipelineDuplicateHandle: Duplicates a pipeline handle. Both the original and duplicated handle must be closed independently with PFEventPipelineCloseHandle.
