A project is a container for the HERE platform resources you use to build an app, service, or other work product. It can contain resources such as catalogs, pipelines, schemas, and services. The project controls which users, apps, and groups can access the resources in the project. We recommend that you use projects to manage all your platform resources.
Some benefits of using projects include:
When you work with projects you will notice the project context is displayed in the portal. For example:
You may change the project context to another project, opt to view all projects or simply remove the project context filter altogether depending on what resources you’re interested in.
To create a project, follow these steps:
After a new project has been created, you can find all your projects here. On this page, you can also find a newly created HRN identifier. A HERE Resource Name (HRN) is a unique identifier of catalog, schema and pipeline resources as well as of platform projects and apps. The HRN is generated automatically by the HERE platform when a resource, project and app is created and cannot be modified. You can use the HRN to specify the project scope for requests to the HERE platform (this is recommended to enable better usage tracking). For additional information, see Create a signature and Billing tags for projects.
You have admin rights to the project you created. You can grant admin rights to other users and apps. For instructions, see Grant or revoke project admin permissions.
Org admins can manage all projects, even if they haven’t been explicitly granted project admin permissions.
By default, all members of the project (including users, groups, and apps) will have access to all resources in the project. You can set up granular access to project resources through platform policies and custom policies using the Command Line Interface (CLI). For more information, see Projects Workflows in the Command Line Interface User Guide.
App managers can specify a default project for the app during or after the creation of the app. This means that requests from this app will be scoped to the specified project by default, allowing you to track usage by this app on a project level.
When creating an app from a project in the Projects Manager, the system will automatically set the default project to the project you are working in. When creating an app from the Access Manager, you can optionally select a project in the "DEFAULT ACCESS TO A PROJECT" field.
To set the default project for the app after it's been created, go to the app details page in the Access Manager, select the Edit app menu option, and select a project in the "DEFAULT ACCESS TO A PROJECT" field.
You can also set the app to only request resources in the scope of the default project by selecting the "Allow access in only default project" checkbox during or after app creation. This setting is recommended for apps using API keys because it helps secure the use of your API keys. It also allows you to track usage by project for an app using an API key.
Apps set to only request resources in the scope of the default project cannot be added to groups. This is to prevent the app from inadvertently becoming a member of other projects (via its group membership) where it won't work since it's restricted to use in another project.
If you need to use an app across multiple projects, for example to orchestrate CI/CD processes, we recommend you use OAuth tokens and set the project scope as needed when requesting the token.
Only org and project admins can change a user's project permissions. Org admins can change user permissions on any project. Project admins can change user permissions only on those projects for which they have admin permissions.
While an app cannot be given org admin or group admin rights, you can make an app a project admin in the same manner as you make a user a project admin. Groups cannot be project admins.
From within a platform project you can create, delete, link, and share resources in a controlled manner. This is the recommended way to manage access to resources. The following sections provide instructions on how to manage project resources by resource type.
There are multiple ways to add a catalog to a project. You can create a new catalog in a project, link to an existing HERE catalog from a project, or link to a catalog that's been created in another project in your org and made available to link, designated as "shared," to your project.
Sharing a catalog makes it available to link to other projects in your organization. You may choose to make the catalog available to all or specified projects within your organization with permissions that you set ("read" and/or "write"). Once you make the catalog available, you can link to it by following the instructions in Add a catalog to a project.
The steps above describe this functionality in the context of Projects Manager. This functionality is also accessible to users with manage access to a catalog from the catalog detail page in the Data section of the portal. In addition, users with manage access to a catalog can unlink that catalog from a project from the Availability tab of the catalog detail page in the Data section of the portal. The steps for all of these actions are described in the Data User Guide.
To make a catalog unavailable to link to projects, follow these steps:
Disabling catalog sharing does not unlink it from projects to which it is already linked. A user with manage access to the catalog can unlink it from a project from the Availability tab of the catalog detail page in the Data section of the portal as described in the Data User Guide.
To change the available permissions to a catalog after you have shared it, follow these steps:
Changing a catalog's permissions in a project will not change the permissions to the catalog for any project that has already linked to the catalog.
There are multiple ways to add a schema to a project. You can create a new schema in a project, link to an existing HERE schema from a project, or link to a schema that's been created in another project in your org and made available to link, designated as "shared," to your project. Linking schemas, whether user or HERE created, is currently only supported via the CLI.
To create a new schema in a project, you must associate the schema with the project when you create the schema's Maven project using the HERE Data SDK for Java and Scala. To associate the schema with a project, specify the project's HERE resource number (HRN) in the
here.token.scope property in your local
~/.here/credentials.properties file before you deploy the Maven project. Then, when you deploy the Maven project containing the schema, the schema deployment plugins will create the schema in the specified HERE platform project. For more information, see Create and Extend Schemas.
After you deploy the schema, it is listed in the project on the Resources tab, in the Schemas section.
Schemas associated with catalogs that are linked to a project are not listed in the Schemas section of the Resources tab. You can view them by navigating to the Data section of the portal, selecting Schemas, and then selecting the project you want from the dropdown menu in the top right corner of the window.
To link a schema that's been shared to a project, see the CLI documentation here.
Sharing a schema makes it available to link to other projects in your organization. You may choose to make the schema available to all or specified projects within your organization with "read" permissions. For more information, see the CLI documentation here.
Once you share a schema, an app in the project to which it has been shared can link to the schema. For more information, see the CLI documentation here.
To add a pipeline to a project, you must create the pipeline in a project. You cannot link an existing pipeline to a project.
To create a new pipeline and add it to a project, follow these steps:
To add a HERE service, such as HERE Routing or HERE Search - Forward Geocoder, link it to your project by following these steps:
To remove a HERE service, such as HERE Routing or HERE Search - Forward Geocoder, from a project, follow these steps:
To delete a project, you first must delete any resources created in the project. Deleting resources in a project could have an impact on all the users, apps, and groups that are members of the project, as well as members of other projects that have linked to resources in your project, so please proceed with caution. Once you've deleted the project resources, delete your project by following these steps:
To delete a project, verify that your role is either ProjectAdmin or OrgAdmin. Other roles do not have permission to delete a project.
Once you delete a project, the Project ID of the deleted project cannot be reused for a new project.
|Maximum number of users/apps in a project||500|
|Maximum number of groups in a project||100|
|Maximum number of projects a group, user, or app can have direct access to||50|
|Maximum number of resources in a project||100|
The information in this section describes how to use projects in the platform portal. You can also use the CLI to work with projects. For more information, see Project Workflows in the Command Line Interface User Guide.