#capjava

2025-03-12

The Transactional Outbox pattern is a key pattern to atomically update the database of a microservice and send related messages to other microservices forming a cloud native application. The SAP Cloud Application Programming Model (CAP) provides a transactional outbox since the support for asynchronous communication using message brokers was introduced. As of early 2024, it can also be used via a public API by stakeholders. It does not only support services provided by the CAP framework but also other, even custom CAP services.

In error situations, it can happen that outbox entries become dead, i.e., the outbox tried to process the entries for a configurable number of times. If the attempts exceed the limit, the corresponding entries are not going to be processed again. I wrote a step-by-step guide in CAPire that shows you how you can manage those entries, the Outbox Dead Letter Queue.

#sapcap #capjava @sapcap @capjava

2025-01-28

SAP Cloud Application Programming Model for Java 3.7.0 is out. Grab it while it's hot!

#sapcap #cap #capjava @sap @sapcap @capjava

https://central.sonatype.com/artifact/com.sap.cds/cds-services-bom/3.7.0

2025-01-22

A Kotlin-based CAP Java Application (Part 1)

Introduction

I recently asked myself whether it is possible to develop a full-fledged cloud application using Kotlin and the SAP Cloud Application Programming Model for Java (CAP Java). Instead of only thinking about it, I decided to start a project to check this.

I'm developing the application in several steps, each step is accompanied by a small blog article. I won't go into every detail when it comes to CAP Java, so knowledge in this area is beneficial to follow the steps.

The application will be a link aggregator where users can add URLs to interesting information on the web. Links can be marked as private, mutual (only visible for other logged-in users), and public (visible for all).

Creating and Adjusting the Project

The first step is to create a CAP Java project as described in CAPire. I'm not going to go into depth here but only show what needs to be changed to use Kotlin for developing the microservice. Make sure that you have a model and database for local development. I chose SQLite to be on the safe side when it comes to integration of multi-tenancy in a later step.

Let's start with the required changes in the parent pom file.

1. Add a property for the Kotlin version in the <properties>:

<kotlin.version>2.1.0</kotlin.version>

2. Add the dependency for the Kotlin standard library to the dependency management:

<!-- KOTLIN -->  
<dependency>  
    <groupId>org.jetbrains.kotlin</groupId>  
    <artifactId>kotlin-stdlib</artifactId>  
    <version>${kotlin.version}</version>  
</dependency>

3. Add the Kotlin compiler plugin:

<!-- KOTLIN PLUGIN -->
<plugin>
	<groupId>org.jetbrains.kotlin</groupId>
	<artifactId>kotlin-maven-plugin</artifactId>
	<version>${kotlin.version}</version>
	<executions>
		<execution>
			<id>compile</id>
			<goals>
				<goal>compile</goal>
			</goals>
			<configuration>
				<sourceDirs>
				<sourceDir>${project.basedir}/src/main/kotlin</sourceDir>
				<sourceDir>${project.basedir}/src/main/java</sourceDir>
				</sourceDirs>
			</configuration>
		</execution>
		<execution>
			<id>test-compile</id>
			<goals>
				<goal>test-compile</goal>
			</goals>
			<configuration>
				<sourceDirs>
				<sourceDir>${project.basedir}/src/test/kotlin</sourceDir>
				<sourceDir>${project.basedir}/src/test/java</sourceDir>
				</sourceDirs>
			</configuration>
		</execution>
	</executions>
</plugin>

4. Adjust the Java compiler plugin:

As we still need Java compilation of the POJOs generated by the CDS compiler we have to adjust the settings of the Java compiler plugin. This is the change entry:

<!-- JAVA COMPILER -->
<plugin>
	<artifactId>maven-compiler-plugin</artifactId>
	<version>3.13.0</version>
	<configuration>
		<release>${jdk.version}</release>
		<encoding>UTF-8</encoding>
	</configuration>
	<executions>
		<execution>
			<id>default-compile</id>
			<phase>none</phase>
		</execution>
		<execution>
			<id>default-testCompile</id>
			<phase>none</phase>
		</execution>
		<execution>
			<id>java-compile</id>
			<phase>compile</phase>
			<goals>
				<goal>compile</goal>
			</goals>
		</execution>
		<execution>
			<id>java-test-compile</id>
			<phase>test-compile</phase>
			<goals>
				<goal>testCompile</goal>
			</goals>
		</execution>
	</executions>
</plugin>

As the perent pom is now complete, some changes need to done in the srv/ directory.

1. Add the dependency for the Kotlin standard library:

<!-- KOTLIN -->  
<dependency>  
    <groupId>org.jetbrains.kotlin</groupId>  
    <artifactId>kotlin-stdlib</artifactId>  
</dependency>

2. Create Kotlin source directory:

Create the directory srv/src/main/kotlin, create the base package for your project and add the Kotlin class Application in the base package with the following content:

package io.github.linkaggregator  
  
import org.springframework.boot.SpringApplication  
import org.springframework.boot.autoconfigure.SpringBootApplication  
  
@SpringBootApplication  
open class LinkAggregatorApplication  
  
fun main(args: Array<String>) {  
    SpringApplication.run(LinkAggregatorApplication::class.java, *args)  
}

3. Delete the Java source directory:

As we want to develop the service in Java, the directory srv/src/main/java can be deleted now.

Now you can build and run the service!

That's it for the first part of this series. You can find the sources for this part on Github.

In the next part we're going to switch to Groovy and Spock to develop unit tests. So stay tuned!

@sap @sapcap #sapcap #cap #capjava #java #kotlin #cloud #sapbtp #btp

Client Info

Server: https://mastodon.social
Version: 2025.04
Repository: https://github.com/cyevgeniy/lmst