What Is a Workspace?

All of your work in VB Studio is done in the context of a workspace, a completely private area where you can work on your extension. Before you can use the Designer to create an App UI or configure an Oracle Cloud Application, you must first select or create a workspace, which defines:

  • The Git repository where your files will be stored. Physically, you work within a copy of the Git repository, called the local repo, and push your changes periodically to the remote repo, which belongs to the project you’re working within.
  • The branch containing the source files you want to use.
  • The Oracle Cloud Applications environment where you plan to publish your extension.
  • A sandbox, if you’re using one, which contains data model changes that haven't been published yet. (The data model changes that have been published are already available to your extension.)
Description of workspacesandrepos.png follows
Description of the illustration workspacesandrepos.png

This figure shows how Sue and Fadi, who both belong to the same project, can have multiple workspaces focused on different extensions. VB Studio projects are usually defined by an administrator, one per discrete software effort. For example, you might have one project for building a bespoke visual application, and another project for all the configurations your team is making to Oracle Cloud Applications. In this figure, notice how each workspace uses separate branch within a clone (the local repo) of the project’s Git repository (the remote repo), periodically using standard Git commands like Commit, Push, and so on to copy updates to the remote repository, like this: Description of gitcommands.png follows
Description of the illustration gitcommands.png

If you're not familiar with working in Git, this video will help you learn the basics:

When working within a workspace, keep the following in mind:

  • The development environment must already be set up and defined in the VB Studio project before you can create a workspace. It's important your environment's Oracle Cloud Applications instance is connected to VB Studio as an IDCS resource (using the Identity Domain option). With this setup, VB Studio can make REST calls against the Oracle Cloud Application instance using the identity of the logged-in user to load application pages in the Page Designer, load the Business Rules editor, or preview changes. This allows the user editing an Oracle Cloud Applications page to perform the necessary functionality in VB Studio based on their assigned roles or privileges. If the instance was connected using Basic Auth or OAuth, REST calls against the Oracle Cloud Applications instance would use the identity of the user whose credentials were used to create the connection—instead of the user editing the Oracle Cloud Applications page—and, in some cases, fail to deliver the intended outcome.
  • You have several options when creating a workspace; which method you choose depends on how you’re working within the project:Description of cr8workspace.png follows
    Description of the illustration cr8workspace.png

    See Get Started for guidance on when to create a new workspace (that is, a new extension), when to import, and when to clone.

  • Depending on your needs, you may have one single project for all your Oracle Cloud Application configurations, with a different Git repo dedicated to each pillar—like HCM, CRM, and so on. Or you might have things separated by pillar, with one whole project dedicated to each pillar's extension work. Regardless, each time you click Edit Page in Visual Builder Studio while looking at an Oracle Cloud Applications page, VB Studio checks to see if there's already a project started with a Git repository for that Oracle Cloud App. If there is, VB Studio clones the Git repo as the basis for your workspace.
  • Your workspace is based on the Oracle Cloud Application you were viewing when you clicked Edit Page in Visual Builder Studio to jump over to Visual Builder Studio. If you choose New Application Extension to create a new App UI (essentially, creating an empty extension), your base application is the Unified Application, which underlies all App UIs in the Oracle Cloud Application ecosystem. This doesn’t mean you’re limited to working on a brand new App UI in your extension. If you later decide that you want to configure an App UI within the same workspace, you can always add that App UI as a dependency, then create a new branch in your workspace to make those changes. (You add something as a dependency when you want to a) configure it (that is, make changes to it), or b) access its resources, like service connections or Layouts, while building your own App UI.)

    Likewise, if your workspace is originally based upon an Oracle Cloud Application that is also an App UI, like Digital Sales, you can still create a brand new App UI in your extension by clicking + App UI:
    Description of appuispanel.png follows
    Description of the illustration appuispanel.png

  • You're the only one who can access your workspace. Changes to files you make in your workspace aren't visible to other team members until you a) merge them to the project's Git repo, b) choose to share them with others for testing, or c) Publish them. See Preview, Share, and Publish Your Extension for more.
  • As explained in Work With Multiple VB Studio Instances, every TEST and DEV instance in your Oracle Cloud Application environment family receives its own instance of VB Studio, and your identity is different on each VB Studio instance you're working with. For example, in the development instance DEV1, your user name might be known as JoeSmith@<Oracle Cloud Applications-instance-name>-DEV1 to VB Studio, while on DEV2 your user ID is JoeSmith@<Oracle Cloud Applications-instance-name>-DEV2, and so on. Because workspaces operate on a per-user basis, you will likely end up with more than one workspace, one for each of your user identities. If you're going to work on the same set of files from more than one instance (that is, from more than one workspace), it's important to publish (or merge) your changes from one workspace before switching to another. This helps to avoid merge conflicts and ensures that you have the very latest changes before you resume your work.