← Back to Recording

Summary

Overview

This course session provides a comprehensive, hands-on walkthrough of developing and deploying an application using Business Work (BW) version 6. The session covers application architecture, module and process design, database integration via JDBC components, data mapping with XPATH/XPACK, error handling, debugging, and deployment configuration. The instructor guides the learner through building a claims processing system that validates policy existence, inserts claim records into a database, retrieves customer data from a CRM system, and returns structured responses. The session concludes with troubleshooting a failed conditional flow and introduces the theoretical infrastructure model of BW6 (Domain, AppSpace, AppNode).

Topic (Timeline)

1. Review of Previous Day: Deduplication and Application Structure [00:02:46.580 - 00:09:00.390]

  • Reviewed the concept of string deduplication in BW: only applies to string data types; does not work for integers, flows, or custom classes.
  • Confirmed that deduplication requires explicit string conversion for non-string types.
  • Introduced the application structure in BW: every application must contain at least one addModule (application-specific logic) and may include zero or more shareModules (reusable across applications).
  • Explained that both module types are composed of processes, and each module must contain at least one process.
  • Discussed architectural rationale for modularization: functional separation and layer separation (e.g., service layer vs. backend processing layer).
  • Emphasized that each module runs on a separate thread.

2. Process Design: Single vs. Subprocesses and Resource Management [00:09:00.390 - 00:13:07.910]

  • Compared using a single process (shared memory, less resource usage, harder to debug/reuse) vs. multiple processes (modular, testable, reusable, but higher memory and CPU cost due to separate threads).
  • Introduced subprocesses: can be shared within the same project, but do not share memory with parent process; data must be passed via parameters.
  • Advised passing only necessary data to subprocesses to avoid payload bloat.
  • Highlighted that subprocesses can be configured to run in parallel (separate threads) or sequentially (same thread), depending on project needs.
  • Noted that sequential subprocesses execute on the same thread due to functional dependency.

3. Practical Implementation: Building the Claim Processing Application [00:13:07.910 - 00:26:23.750]

  • Launched the BW6 environment and began building the application with a parent process (clientService) and subprocesses (normalize, validatePolice, addClaim).
  • Configured JDBC components: explained four types — stored procedure, query, DML, and SQL Direct (for DDL).
  • Implemented validatePolice to check policy existence: if not found, throws error (400); if found, proceeds to addClaim.
  • Configured addClaim to insert claim data into database using SQL INSERT with parameters: clientID (UUID), policyID (integer), type (varchar), amount (float), status (hardcoded as "pending"), and created_at (using PostgreSQL now()).
  • Mapped input data from normalize to addClaim using XPACK expressions.
  • Fixed XPACK typecasting error: resolved integer-to-integer mismatch by using typecast in the error view.
  • Corrected record filter in XPACK: changed from filter to 1 (XPACK uses 1-based indexing, not 0-based).
  • Defined output schema (responseValidatePolicy) using OpenAPI/json format: fields included fullName, clientID, email, and policyID.
  • Hardcoded sample output values for testing: fullName = "John Néstor", policyID = 1.

4. Application Assembly, Debugging, and Deployment [00:26:26.160 - 00:39:04.220]

  • Fixed configuration error: removed empty process property causing red error flag.
  • Assembled the main process flow: normalize → validatePolice → addClaim.
  • Mapped inputs from parent process (normalizePayload) to subprocess (validatePolice) using auto-map for complex objects.
  • Updated output mapping: sourced fullName from validatePolice output instead of normalize.
  • Configured Postman for testing: set credentials (admin@example.com / admin) and targeted localhost:881.
  • Verified database state: 4 existing claims, 3 policies (IDs 1, 2, 3).
  • Initiated application deployment via Run Configuration, ensuring clientService was selected as the entry point.

5. Database Integration Error and Resolution [00:39:04.220 - 00:53:38.670]

  • Initial test failed: “relation claims does not exist” — caused by JDBC resource pointing to CRM database instead of corePolicy.
  • Corrected JDBC resource configuration: switched from jdsproperty1 to jdsproperty and redirected to corePolicy database.
  • Re-deployed application after configuration fix.

6. Type Conversion and Final Data Insertion [00:53:38.670 - 00:59:43.740]

  • New error: “UUID expected, got character” — resolved by casting clientID in SQL statement using CAST(? AS UUID).
  • Corrected syntax: wrapped parameter in CAST(? AS UUID) with proper spacing and capitalization.
  • Successfully inserted claim record into claims table (count increased from 4 to 5).

7. Retrieving Customer Data via CRM and Finalizing Response [00:59:43.740 - 01:09:40.080]

  • Added new JDBC Query component: findDataClient to retrieve customer info (name, email) from CRM using customerPoliceLink and customer tables.
  • Wrote SQL JOIN query: SELECT c.fullname, c.email FROM customerPoliceLink cp JOIN customer c ON cp.customerid = c.customerid WHERE cp.policyid = ?.
  • Configured parameter policyID (integer) and used fetch to define output columns.
  • Mapped policyID from start to findDataClient input, resolved XPACK typecast error again.
  • Mapped output: fullName and email from findDataClient to final response; clientID and policyID from start.
  • Fixed record filter again: changed from filter to 1 for 1-based indexing in XPACK.

8. Testing, Debugging, and Conditional Flow Issue [01:09:40.080 - 01:20:15.820]

  • Tested with policyID = 1: returned correct customer data (John Néstor) and inserted claim.
  • Tested with policyID = 5 (non-existent): received “null pointer” error — expected 400, but flow continued.
  • Debugged using debugger mode: found that validatePolice condition (count > 0) was not being evaluated correctly.
  • Observed that query returned no rows, but condition did not trigger “throw” path — suspected issue with SQL result handling or condition logic.
  • Noted unresolved issue: condition logic not functioning as expected; deferred deeper investigation.

9. BW6 Infrastructure Overview: Domain, AppSpace, AppNode [01:20:15.820 - 01:22:36.500]

  • Introduced theoretical architecture of BW6: on-premise deployment requires three layers:
    • TA Server: central administration server.
    • BW Admin: GUI tool to manage domains, AppSpace, and AppNode.
    • Domain: logical grouping of applications.
    • AppSpace: container for applications (like a namespace).
    • AppNode: runtime execution environment (worker node).
  • Mentioned key commands: create domain, create space, create node.
  • Emphasized that practical development (as done in session) abstracts infrastructure setup, but production requires explicit configuration via BW Admin.

Appendix

Key Principles

  • Deduplication: Only applies to string types; non-string types require explicit conversion.
  • Modular Design: Use addModule for app-specific logic; shareModule for cross-app reuse.
  • Process Architecture: Prefer subprocesses for testability and reusability; accept higher resource cost.
  • XPACK Indexing: Always use 1-based indexing (e.g., record[1]), not 0-based.
  • JDBC Configuration: Ensure correct database connection (resource) and schema (table) alignment.
  • Type Safety: Use CAST(? AS UUID) or typecast in XPACK to resolve type mismatches between data sources.

Tools Used

  • Business Work (BW) 6: Application development platform.
  • Postman: API testing client.
  • pgAdmin / psql: Database query interface for PostgreSQL.
  • BW Admin: Infrastructure management tool (theoretical context).

Common Pitfalls

  • Misconfiguring JDBC resources to point to wrong database (e.g., CRM instead of corePolicy).
  • Forgetting to set record filter = 1 in XPACK, leading to null or incorrect data extraction.
  • Not casting data types in SQL (e.g., string to UUID) when database schema enforces strict types.
  • Leaving empty process properties, causing silent deployment failures.
  • Assuming 0-based indexing in XPACK (common mistake for developers from other languages).

Practice Suggestions

  • Build a new application with two addModules: one for validation, one for notification.
  • Create a shareModule with reusable data transformation logic (e.g., date formatting, ID normalization).
  • Test edge cases: null policyID, empty customer data, invalid UUID format.
  • Use debugger mode to step through conditional flows and inspect variable states.
  • Always validate database schema and column types before writing SQL in BW.