Hypersync apps expose the data in an external service in the form of proof types. For example, a Hypersync app for a user directory service might expose the following proof types:
- List of Users
- List of Groups
- Group Membership
Each one of these proof types selects the appropriate data from the external service and formats it as appropriate for the type of data. Data can be formatted in tabular, stacked and hierarchical layouts.
Once the user selects a proof type, they may be asked for one or more criteria values. The Group Membership proof type, for example, will likely reuqire that the user specify the name of the group that they are interested in. This information is then used to filter the group membership data. The metadata for these criteria values (e.g. whether the group name is shown as a select control or a text field) comes from the criteria provider.
Proof types retrieve data from the app's data source by name. The proof type may also provide parameter values to the data source to ensure that the right data is returned.
A proof type may format the data in the following ways:
| Layout | Description |
|---|---|
| Tabular | Data is arranged in a table where each row is an item in the data set. |
| Stacked | Fields in an item are arranged verticially, and that vertical stack is repeated for every row in the result set. |
| Hierarchical | A combination of tabular and/or stacked layouts where some layouts are nested. |
Tabular and stacked layouts can be output as PDF or Excel files. Hierarchical layouts can only be output as PDF.
Tabular and stacked layouts can also be described declaratively using JSON files, while hierarchical proof types currently cannot.
The Hypersync SDK makes it possible to define most common proof types using declarative JSON files. Because these JSON files are easy to read and to edit, this no-code solution is recommended over writing TypeScript / JavaScript code for a proof type.
The proof type JSON files live in the /json/proof directory. This directory contains one JSON file per proof type. To learn more about the format of these JSON files, see Proof Type JSON or check out the examples in the Hypersync SDK Samples repository.
The /json/proofTypes.json file lists the set of proof types that are currently exposed by an application. Any proof type JSON files that are in your project but not listed in proofTypes.json will not be shown to the user. This makes it possible to develop new proof types without exposing them to users until you are ready.
For more information on proofTypes.json, see Proof Types JSON Format.
For proof types that are hierarchical or which have other features which don't align with the no-code approach, the SDK makes it possible to author proof types in code.
When using code, each proof type is represented as a "proof provider" component. These components derive from the SDK's ProofProviderBase:
export class MyProofProvider extends ProofProviderBase {
async generateCriteriaMetadata(
criteriaValues: HypersyncCriteria,
pages: ICriteriaPage[]
): Promise<ICriteriaMetadata> {
// TODO: Generate the metadata for the criteria that are shown
// to the user when configuring this proof type. Will generally
// defer to a class that implements ICriteriaProvider.
}
async generateSchema(
criteriaValues: HypersyncCriteria
): Promise<IHypersyncSchema> {
// TODO: Generate the schema for the proof type. This schema information
// is used by Hyperproof's automated testing feature.
}
async getProofData(
hypersync: IHypersync,
hyperproofUser: IHyperproofUser,
authorizedUser: string,
syncStartDate: Date,
page?: string,
metadata?: SyncMetadata
): Promise<IGetProofDataResponse | IProofFile[]> {
// TODO: Fetch the data from the service and format it.
}
}
Custom proof provider classes should live in the proof-providers directory in your package. There should also be an index file (i.e. index.ts or index.js) that exports each of the proof provider classes.
index.ts Example
export * from './ListOfUsers';
export * from './ListOfGroups';
export * from './GroupMembership';