Reasons to use Projects:
- Build, Manage and Monitor in one place.
- Manage integrtaion releases.
- Control access with RBAC.
- Use and customize prebuilt accelerators.
- Design: we can design our integrations, create lookups, connections etc. And run or test the integrations.
- Observe: we can view the integrations, instances, future runs and audit info
- Deploy: we can create a deployment of the project, we can select the integrations of the project to be part of the deployment with versions. After creating the deployment, we can export it and use or import it to higher instance. Also we can activate or deactivate the deployment.
Differences between Packages and Projects:
Area | packages | projects |
---|---|---|
Overall Usage & Goals | Packages provide for organization of integrations to allow for import and export of related resources. | In addition to resource organization, projects provide for improved release management and a single unified workspace. |
Access Control | Resources within packages are visible to all OIC users the same as all other global resources. | Projects provide for fine-grained access control. |
Deployment | Creating a CI/CD pipeline to deliver updated integrations to other environments requires work outside of OIC | Projects provide built-in deployment capabilities with release management and controlled deployment capabilities. |
Observability | Packages do not provide separate monitoring capabilities. | Projects provide internal Observe pages for monitoring activated project integrations. |
- Project access is determined by both OIC service roles and project roles.
- Suppose someone has project edit role but has service monitor role, then he would only be able to monitor.
- Suppose someone has project monitor role but has servicedeveloper role, then he will only be able to monitor.
- For packages, export creates a .par file and for projects, export creates a .car file.