top of page

Autogenerate Code ??

  • Writer: Anand Nerurkar
    Anand Nerurkar
  • Sep 5
  • 4 min read

🔑 1. Reality Check — No One-Click Tool Exists

  • There is no fully automated, 1:1 converter that takes PL/SQL and generates production-quality Java microservice code.

  • Tools like Ora2Pg or AWS Schema Conversion Tool (SCT) can help with schema conversion and partially convert PL/SQL to pseudo-code, but you still need manual refactoring to create clean, domain-oriented microservices.

🏗 2. Recommended Approach

Step 1: Generate Baseline Code (Semi-Automated)

  • Use AWS SCT, Ora2Pg, or Oracle SQL Developer to:

    • Extract package procedures/functions.

    • Generate equivalent Java/JDBC stubs (often verbose, not clean).

    • Get a baseline of SQL statements to be executed from Java.

Step 2: Manual Refactoring

  • Rewrite business logic into Spring Boot service classes.

  • Convert SQL queries into:

    • JPA repositories (for simple CRUD).

    • Named queries/native queries (for complex joins).

  • Map IN/OUT parameters of PL/SQL procedures → Java DTOs.

  • Add transaction boundaries (Spring @Transactional) carefully.

  • Implement error handling using custom exceptions and global exception mappers.

⚙️ 3. Industrialization (Templates & Generators)

To speed up migration, we built code generation templates and automation:

Artifact

Approach

DTOs & Entities

Generated from DB schema using Hibernate Tools or JHipster entity generator.

Repository Layer

Auto-generated Spring Data JPA repositories.

Controller/Service Skeletons

Generated via custom code templates (e.g., Freemarker, Mustache).

Tests

Auto-generate baseline unit tests (e.g., using OpenAPI spec + RestAssured).

This reduced boilerplate work by ~50%, so we could focus on rewriting business rules rather than plumbing code.

🧠 4. Example Interview-Ready Narrative

You can say something like this:

“Once we identified the service boundaries, we didn’t blindly hand-convert PL/SQL line by line.We used AWS SCT to extract PL/SQL logic and generate baseline Java code, but that was just scaffolding.Then we manually rewrote the core business logic into Spring Boot services, using JPA for persistence and Kafka for async workflows.We also built internal code generation templates for entities, repositories, and controller skeletons — so developers could focus on translating business rules, not writing boilerplate.This semi-automated approach gave us speed and consistency while ensuring code quality and maintainability.”

🚧 5. Key Considerations (Mention in Interview)

  • Automation helps only for CRUD-heavy code — complex PL/SQL logic still needs domain knowledge.

  • Golden test dataset is crucial — run old PL/SQL and new microservice on same input, compare output.

  • Parallel run for few weeks before decommissioning PL/SQL.

  • Performance tuning after migration (indexes, batching, caching).

🛠 6. Tooling Stack You Can Mention

  • AWS Schema Conversion Tool (SCT) – converts schema + PL/SQL to Java stubs.

  • Ora2Pg – for schema + code migration (if moving away from Oracle).

  • JHipster / Spring Initializr – for microservice scaffolding.

  • Hibernate Tools – for entity generation from DB schema.

  • Liquibase/Flyway – for DB migration scripts.

Key Takeaway for Interview:You didn’t just rewrite everything manually (which sounds inefficient), and you didn’t just trust a black-box tool (which sounds risky).You combined semi-automated code generation + manual domain refactoring + automated testing for a balanced, industrialized approach.


Once we have schema in place, we need to expose those microservices , can we autogenerate microserices end to end code


Yes – you absolutely can automate a large part of microservice code generation once the schema and service boundaries are finalized – and this is something senior architects are expected to know.


Let’s go step by step and make it interview-ready.

🏗 1. What Can Be Auto-Generated vs. What Must Be Manual

✅ Good Candidates for Auto-Generation:

  • Entities / DTOs → from schema (tables, columns)

  • Repository layer → JPA Repositories or MyBatis mappers

  • CRUD APIs (Controllers) → REST endpoints for basic Create/Read/Update/Delete

  • OpenAPI Spec / Swagger → API contract from schema

  • Dockerfile, Helm charts, CI/CD pipeline stubs → Infra-as-Code templates

❌ Still Requires Manual Work:

  • Business logic / orchestration rules

  • Domain event publishing (Kafka topics, outbox pattern)

  • Security & role-based access control

  • Complex validations & workflows

  • Unit/integration test customization beyond baseline

⚙️ 2. End-to-End Code Generation Approach

Step 1: Generate Entities & Repositories

  • Use Hibernate Tools or Spring Data JPA entity generator to generate:

    • @Entity classes from DB schema

    • JpaRepository interfaces for persistence

mvn hibernate3:hbm2java

or use JHipster which generates entity + repository + REST resource.

Step 2: Generate API Contract

  • Use OpenAPI Generator or Swagger Codegen:

    • Define API contract in OpenAPI YAML

    • Generate controller & model stubs in Java

openapi-generator-cli generate \
  -i loan-service-api.yaml \
  -g spring \
  -o loan-service

This gives you:

Step 3: Generate Service Skeleton

If you want to go further, tools like JHipster or Spring Roo can generate full CRUD microservice:

jhipster import-jdl loan-service.jdl

Generates:

  • Entities + Repositories + Services + Controllers

  • Preconfigured Spring Boot app with logging, security, caching, Swagger UI

Step 4: CI/CD & Deployment

  • Scaffold Dockerfile and Kubernetes manifests:

jhipster docker-compose
jhipster kubernetes

Or use Helm Chart templates for deploying on AKS/EKS/GKE.

🛠️ 3. Tools & Frameworks You Can Mention

Purpose

Tools

Entity & Repo Generation

Hibernate Tools, JHipster, Spring Roo

API Contract → Code

OpenAPI Generator, Swagger Codegen

CI/CD Scaffolding

JHipster CI/CD sub-gen, Jenkins Shared Libraries, Tekton

Infra-as-Code

Helm, Kustomize, Terraform for service + infra creation

Pipeline Templates

Azure DevOps YAML templates, GitHub Actions Reusable Workflows

🎯 4. Interview-Ready Narrative

Here’s how you can explain it:

“Once we had the schema and service boundaries finalized, we wanted to accelerate delivery and avoid writing boilerplate manually.We used OpenAPI first approach – design API contracts, then generate Spring Boot controller stubs using OpenAPI Generator.For persistence, we generated entities and repositories from schema using Hibernate Tools and Spring Data JPA.For new services, we used JHipster to scaffold complete CRUD microservices including security, Swagger UI, Dockerfile, and Kubernetes manifests.This automation gave us 50–60% code coverage upfront – developers could then focus on actual business logic, validations, and event publishing rather than wiring and plumbing.”

🔑 5. Key Benefits (Mention in Interview)

  • Speed – weeks saved on repetitive coding.

  • Consistency – same structure, logging, error handling across services.

  • Governance – enforces enterprise standards (naming conventions, security).

  • CI/CD ready – generated apps already containerized.

🚧 6. Pitfalls & Mitigation

Pitfall

Mitigation

Generated code is verbose or non-idiomatic

Run code review + refactor templates

Too many CRUD endpoints expose DB as-is

Apply DDD – only expose relevant aggregates

Developers rely too much on automation

Use as scaffold only, enforce manual domain logic implementation

Security left out

Add Spring Security & role mappings in templates

Key Takeaway for Interview:You can confidently say you industrialized microservice creation by combining code generators (OpenAPI, JHipster) with manual business logic implementation. This shows you know how to balance automation with craftsmanship.

 
 
 

Recent Posts

See All
How to replan- No outcome after 6 month

⭐ “A transformation program is running for 6 months. Business says it is not delivering the value they expected. What will you do?” “When business says a 6-month transformation isn’t delivering value,

 
 
 
EA Strategy in case of Merger

⭐ EA Strategy in Case of a Merger (M&A) My EA strategy for a merger focuses on four pillars: discover, decide, integrate, and optimize.The goal is business continuity + synergy + tech consolidation. ✅

 
 
 

Comments

Rated 0 out of 5 stars.
No ratings yet

Add a rating
  • Facebook
  • Twitter
  • LinkedIn

©2024 by AeeroTech. Proudly created with Wix.com

bottom of page