SAP Business Application Studio Basics: Dev Spaces, Projects, and HANA Development

SAP Business Application Studio (BAS) is a browser-based development environment for building SAP applications with a project-focused workspace. Its core unit is the dev space: an isolated environment that contains the runtime, tools, and extensions needed for a specific development scenario.

For SAP HANA development, BAS is most useful when the team standardizes its project structure, selects a suitable dev space, connects to the intended database or service, and validates changes before deployment. This guide focuses on those operational steps and the troubleshooting decisions that matter in a real development workflow.

01Understand the BAS workspace

A BAS workspace combines a file explorer, source editor, terminal, extension management, source-control integration, and project-specific commands. The exact tools available depend on the dev space definition and the extensions installed in it.

A dev space should contain only the capabilities required for the project. A smaller environment is easier to start, easier to troubleshoot, and clearer for new team members. Typical HANA-oriented workspaces include database development tools, application runtimes, source-control support, and deployment utilities.

Keep project files in the workspace and commit source code to the team repository. Treat the dev space as a working environment rather than the authoritative storage location. This approach makes it possible to recreate the environment when a dev space expires, is deleted, or needs a different toolset.

02Set up a BAS dev space

Start the setup with the project requirements rather than with a large collection of extensions.

1. Open SAP Business Application Studio and choose Create Dev Space.
2. Select the development scenario that matches the project, such as SAP HANA development or application development.
3. Add only the extensions required for the selected framework, database access, testing, and source control.
4. Create the dev space and wait until its status is running.
5. Open the workspace and confirm that the terminal, source control view, project generator, and database tooling are available.
6. Clone or open the project repository.
7. Read the project README before running installation or deployment commands.

Record the dev space type and required extensions in the project documentation. Teams that rely on undocumented personal extensions often see different build results between developers.

A dev space restart is useful after an extension change or a runtime problem. Reopening the browser tab alone does not always reload the complete workspace environment.

03Choose the right project structure

The project structure should reflect the application architecture. A HANA application commonly separates database artifacts, service or application code, configuration, tests, and deployment descriptors.

For projects using HDI, the database module contains deployable database artifacts and the application module consumes the services exposed by the database layer. Keep database objects in the database module and application logic in the application module. This separation makes deployment order and ownership easier to understand.

The SAP HANA HDI containers guide explains the container-oriented development model used by many HANA application projects. Use that model when the project requires isolated database artifacts, controlled deployment, and application bindings.

Before generating files, identify:

• The application runtime and entry point
• The database module and its deployment descriptor
• The service or binding used by the application
• The test location and test command
• The deployment target and required credentials
• The source-control branch used for the change

Avoid mixing generated files, local secrets, and temporary build output with committed source code. Use the repository's ignore rules and the project's environment-variable conventions for local configuration.

04Connect development tools to SAP HANA

Database access has two separate concerns: the development tool must reach the database, and the database user must have the privileges needed for the intended operation.

For an on-premise SAP HANA system, the connection path may include network routing, a firewall rule, a corporate proxy, or SAP Cloud Connector. Confirm the approved connectivity path with the system administrator before changing project configuration.

Use SAP HANA database explorer for direct SQL validation when the team has provided an authorized connection. Use SAP HANA cockpit for broader system administration and monitoring. BAS remains the project workspace; these tools provide database and system views that are useful when a build, deployment, or query fails.

Check the following values before diagnosing application code:

• Database host and SQL port
• Database name or tenant target
• TLS requirements and trusted certificates
• User name and authentication method
• Required database roles and object privileges
• Network route from the development environment

Do not store passwords in source files or commit them to the repository. Prefer the approved credential store, environment configuration, or service binding mechanism for the project.

05Build SQLScript and HANA artifacts

SQLScript procedures and table functions should be developed with clear input, output, and error behavior. Keep reusable business logic close to the database layer when it benefits from set-based execution, and keep application orchestration in the application layer.

The SAP HANA SQLScript procedures guide covers the database-side procedure model. Use it alongside the project conventions for naming, parameter types, error handling, and deployment.

For calculation views, define semantics and data consumption requirements before changing nodes or projections. A graphical calculation view can be appropriate for visual modeling and metadata-driven design, while SQL-based approaches can be clearer for logic that is easier to review as code. The SAP HANA graphical vs SQL calculation views comparison helps structure that decision.

Validate database artifacts in small increments:

1. Check the artifact syntax in the editor.
2. Build the database module.
3. Deploy to the designated development target.
4. Confirm the object exists in the expected schema or container.
5. Run a focused query or automated test.
6. Review the deployment output before continuing.

This sequence narrows failures to syntax, build, deployment, authorization, or runtime behavior instead of combining all of them in one test.

06Compare BAS with SAP Web IDE

SAP Web IDE and BAS both provide browser-based development experiences, but BAS is based on a modern development-workspace model with dev spaces, extensions, an integrated terminal, and broader support for current application frameworks.

The practical differences are most visible in project setup and team operations:

Choose BAS when the project benefits from its dev-space model, current extension ecosystem, and integrated command-line workflow. Keep the existing project structure documented when moving a team from SAP Web IDE so that build, deployment, and testing behavior remains visible.

07Run tests and debug failures

Testing should run at more than one level. A database test checks SQLScript, views, procedures, table functions, and data behavior. An application test checks service endpoints, validation, authorization handling, and UI or API behavior.

Use the terminal for repeatable build and test commands defined by the repository. Use the editor's diagnostics for syntax and type feedback. Use application logs, deployment logs, SAP HANA database explorer, and SAP HANA cockpit when the failure crosses the boundary between application code and the database.

When a test fails, classify the failure before changing code:

• Workspace failure: the dev space lacks a required extension or runtime.
• Build failure: a dependency, syntax issue, or project descriptor prevents packaging.
• Connection failure: the host, port, certificate, route, or credential is invalid.
• Authorization failure: the user or service binding lacks a required privilege.
• Deployment failure: the artifact, target, or deployment order is incorrect.
• Runtime failure: the deployed application or database object returns an error.
• Data failure: the test data does not satisfy the expected business conditions.

The SAP HANA app testing and debugging guide provides a broader workflow for separating application, database, and deployment evidence.

Capture the failing command, timestamp, project commit, target database, and relevant log excerpt. This context prevents repeated tests against different code or different targets.

08Troubleshoot BAS dev spaces

A stopped or unavailable dev space is usually handled by checking its status, restarting it, and reviewing the workspace logs. If the problem returns after a restart, compare the current extensions and project dependencies with the documented baseline.

For slow startup or repeated initialization errors, remove unused extensions, reduce unnecessary project processes, and check whether a dependency installation is running during workspace startup. A clean recreation of the dev space can isolate an environment problem from a repository problem.

For database connection errors, test the path in layers:

1. Confirm that the target host and port are correct.
2. Confirm that the development environment can reach the approved network route.
3. Confirm the certificate and TLS settings.
4. Confirm the database user and authentication method.
5. Confirm the target database and schema or container.
6. Confirm the required privilege with the database administrator.
7. Re-run a minimal connection or SQL test before running the full application.

For deployment errors, read the first meaningful error in the deployment log. Later messages often describe cleanup actions rather than the original cause. Check the target, artifact name, service binding, deployment order, and repository commit before repeating the deployment.

09Standardize the team workflow

A reliable BAS workflow has a documented dev space definition, a repository bootstrap procedure, a supported runtime, a repeatable build, and a clear deployment route.

A practical team checklist includes:

• Dev space type and required extensions
• Supported editor and runtime versions
• Repository clone and branch procedure
• Dependency installation command
• Local test command
• Database connection method
• Deployment command or pipeline entry point
• Log locations and escalation details
• Secret-management rules
• Cleanup procedure for temporary artifacts

The SAP HANA development overview connects BAS workspaces with the broader development areas of SQLScript, calculation views, CDS, HDI, testing, and delivery automation.

Review the checklist after each major framework, database, or deployment change. Small updates to the project documentation prevent environment drift and reduce time spent diagnosing setup differences.