Project Guidance If You've Used Packages
If you upgraded from Oracle Integration Generation 2, some of your integrations might be in packages. Learn the key differences between packages and projects and how to get started using projects.
Key Differences Between Packages and Projects
| Area | Packages | Projects |
|---|---|---|
|
Overall usage and goals |
Packages primarily offer help with organization. For example, you can collect related integrations in a single package. You can also import and export packages, including their contents. |
Projects offer many benefits, including improved release management, organization of artifacts, and a single unified workspace for designing, managing, and monitoring integrations. See About Projects. |
|
Access control |
Everyone who works in Oracle Integration can access the integrations in a package. Similarly, everyone can access integrations that aren't part of a package. |
Projects offer fine-grained access control. You choose the people who can edit, view, and monitor the integrations and other assets in each project. |
|
Deployment |
Creating a continuous integration and continuous deployment (CI/CD) pipeline and delivering updated integrations to higher environments requires work outside Oracle Integration. For instance, you can export a package and use the solution of your choice, such as Oracle Visual Studio, APIs, or shell scripts, to move the integrations into a testing or production environment. |
If you've deployed integrations from packages before, deployment is easier and faster from a project. Projects provide built-in deployment capabilities for improved release management, including controlled deployment. Deploy your integrations where you design them, from within a project, without needing to create a pipeline or run a build. |
|
Observability |
Packages don't offer monitoring capabilities. You monitor integrations individually on the Observability pages. |
You have two options for monitoring the integrations in a project: The Observe pages in the project and the Observability pages, which are outside the project. Monitoring within the project provides helpful context for the integrations. |
Workflow for Converting a Package to a Project
If you used packages in Oracle Integration Generation 2, you can convert them to projects in just a couple of minutes using the package conversion tool.
The package conversion tool moves everything in the package into a project, including integrations, connections, lookups, and JavaScript libraries. The existing package remains untouched.
Note:
You can't convert accelerator and recipe packages into projects.| Step | Task | More information |
|---|---|---|
|
1 |
Create a project from a package |
|
|
2 |
Control access to the project by selecting the people who can edit, view, and monitor the project |
If you don't assign access, everyone's access within Oracle Integration determines the work they can do in the project. |
After you've created the project, you can deploy the integrations within it. See Create and Manage a Project Deployment.
Workflow for Importing Standalone Integrations into Projects
Ready to start moving your standalone integrations into projects? All you need to do is spend a few minutes importing the integrations and their components into one or more projects.
| Step | Task | More information |
|---|---|---|
|
1 |
Create a strategy for organizing projects |
|
|
2 |
Create a project |
|
|
3 |
Export the integrations that you want to import into a project |
|
|
4 |
Add one or more integrations to the project |
|
|
5 |
Configure the properties for the connections in the integrations |