Cross-post: this blog has also been posted on SAP Community.
The best way to be able to fix any of your integrations is to be able to run tests really fast. If you are doing SAP CPI development in, for example, Groovy it can be a little challenging to set up test cases for your SAP CPI scripts.
There are a number of different blogs on how to make it possible. I think Eng Swee Yeoh has created a number of blogs on how to test SAP CPI on SAP Community.
You will need some boilerplate code to set up test cases and run and do your verifications. We have now added a way to automate the process.
Last week we showed how we could expose your SAP CPI and API management as a Git repository. In the Git repository, we have added mock services for all the necessary implementations, so it is possible to run the scripts without connecting to the services.
Since it is a mock, some parts of the run may not be 100% accurate if you use some exotic functions. That is why you still should be testing in real CPI.
The only thing you need to do is to add the SAP CPI jars you can download here.
Testing with Figaf
Last week we released a version of the Figaf DevOps Suite that enabled you to expose your SAP CPI content via Git. With this integration, we now have another nice option. We can create unit tests based on your scripts.
If you have created test cases for an iflow in the Figaf DevOps Suite then you have the option to “Generate Groovy Scripts Test data”. This will create test cases for all the scripts that you have in that iflow.
The program will create all input and output messages in a JSON format like the following. This will allow the Figaf DevOps Suite to create automated assertions of all the parameters in the message.
{
"input" : {
"headers" : {
"SAP_MplCorrelationId" : "AF1eZ3x-sdvOIJSgilALr8Lldude",
"CamelHttpResponseCode" : "200",
"apikey" : "124234523",
// ....
},
"properties" : {
"CamelStreamCacheUnitOfWork" : "DefaultUnitOfWork",
"CamelSplitComplete" : "false",
"CamelSplitIndex" : "1",
"CamelCorrelationId" : "ID-vsa6859459-36905-1565339707446-5304-2",
"CamelMessageHistory" : "[DefaultMessageHistory[routeId=Process_1, node=CallActivity_27_1566467962530], DefaultMessageHistory[routeId=Process_17, node=CallActivity_39_1566467962450], DefaultMessageHistory[routeId=Process_17, node=MessageFlow_34_1566467962454], DefaultMessageHistory[routeId=Process_17, node=setHeader13227], DefaultMessageHistory[routeId=Process_17, node=setHeader13228], DefaultMessageHistory[routeId=Process_17, node=to14489], DefaultMessageHistory[routeId=Process_17, node=removeHeader3781], DefaultMessageHistory[routeId=Process_17, node=removeHeader3782], DefaultMessageHistory[routeId=Process_17, node=removeHeader3783], DefaultMessageHistory[routeId=Process_17, node=to14490], DefaultMessageHistory[routeId=Process_17, node=CallActivity_41_1566467962463]]",
".hasMoreRecords" : "false",
// ....
},
"body" : "{\r\n\"d\" : {\r\n\"__metadata\": {\r\n\"uri\": \"https://services.odata.org/V2/Northwind/Northwind.svc/\"type\": \"NorthwindModel.Customer\"\r\n}, \"CustomerID\": \"TOMSP\", \"CompanyName\": \"Toms Spezialit\\u00e4ten\", \"ContactName\": \"Karin Josephs\", \"ContactTitle\": \"Marketing Manager\", \"Address\": \"Luisenstr. 48\", \"City\": \"M\\u00fcnster\", \"Region\": null, \"PostalCode\": \"44087\", \"Country\": \"Germany\", \"Phone\": \"0251-031259\", \"Fax\": \"0251-035695\", \"Orders\": {\r\n\"__deferred\": {\r\n\"uri\": \"https://services.odata.org/V2/Northwind/Northwind.svc/Customers('TOMSP')/Orders\"\r\n}\r\n}, \"CustomerDemographics\": {\r\n\"__deferred\": {\r\n\"uri\": \"https://services.odata.org/V2/Northwind/Northwind.svc/Customers('TOMSP')/CustomerDemographics\"\r\n}\r\n}\r\n}\r\n}"
},
"output" : {
//same as input
}
}It will also create a testing method like the following that contains all the scripts in the flow and link to all the test messages that you have in the repository. You can remove all the scripts that you do not want to be testing with.
Every time you run the generate test case it will update the file and add more test data with an increased number. So you can run generate as many times as you want, but it would be wise to only add each test case once; otherwise, you are not adding any value to the testing.
The generated test case looks like the following. And contains testing of all your scripts.
package com.figaf
import org.junit.jupiter.params.ParameterizedTest
import org.junit.jupiter.params.provider.ValueSource
class GroovyScriptsTest extends AbstractGroovyTest {
@ParameterizedTest
@ValueSource(strings = [
"src/test/resources/test-data-files/SetHeaders2/processData/test-data-1.json"
])
void test_SetHeaders2Groovy(String testDataFile) {
String groovyScriptPath = "src/main/resources/script/SetHeaders2.groovy"
basicGroovyScriptTest(groovyScriptPath, testDataFile, "processData", getIgnoredKeysPrefixes(), getIgnoredKeys())
}
@ParameterizedTest
@ValueSource(strings = [
"src/test/resources/test-data-files/setHeaders/processData/test-data-2.json",
"src/test/resources/test-data-files/setHeaders/processData/test-data-3.json"
])
void test_setHeadersGroovy(String testDataFile) {
String groovyScriptPath = "src/main/resources/script/setHeaders.groovy"
basicGroovyScriptTest(groovyScriptPath, testDataFile, "processData", getIgnoredKeysPrefixes(), getIgnoredKeys())
}
@Override
List<String> getIgnoredKeys() {
List<String> keys = super.getIgnoredKeys()
keys.addAll(Arrays.asList())
return keys
}
}I think this approach will make it a lot easier to set up testing and run a set of assertions. You don’t need to do anything, and all required information is added to the environment. If there are parameters that you want to exclude from your script you can add it to the getIgnoredKeys.
Custom testing
The standard way will only allow you to test input with the expected output. It may not be what you want to do in all cases. There may be test cases you are creating that need to be evaluated differently.
You then have the option to just send a message to the processing and then insert your assertions to the processing. An example of such a testing approach is the following. So here you can do all your custom assertions and get the errors if anything does not match.
An example of such a custom validation could look like the following.
package com.figaf
import org.assertj.core.api.Assertions
import org.assertj.core.api.SoftAssertions
import org.junit.jupiter.api.Test
class SetHeadersTest extends AbstractGroovyTest {
@Test
void customTest() {
String groovyScriptPath = "src/main/resources/script/setHeaders.groovy"
String testDataFilePath = "src/test/resources/test-data-files/setHeaders/processData/test-data-1.json"
def (MessageTestData messageDataExpected, MessageTestData messageDataActual) =
processMessageData(groovyScriptPath, testDataFilePath, "processData")
String actualModeValue = messageDataActual.getProperties().get("newError3")
Assertions.assertThat(actualModeValue).isNotNull()
Assertions.assertThat(actualModeValue)
.endsWith("Test3")
}
@Test
void customTestSoftAssertions() {
String groovyScriptPath = "src/main/resources/script/setHeaders.groovy"
String testDataFilePath = "src/test/resources/test-data-files/setHeaders/processData/test-data-1.json"
def (MessageTestData messageDataExpected, MessageTestData messageDataActual) =
processMessageData(groovyScriptPath, testDataFilePath, "processData")
String actualPropValue = messageDataActual.getProperties().get("newError3")
String expectedPropValue = messageDataExpected.getProperties().get("newError3")
SoftAssertions softly = new SoftAssertions()
softly.assertThat(actualPropValue).isNotNull()
softly.assertThat(actualPropValue).endsWith("Test3")
softly.assertThat(actualPropValue).isEqualTo(expectedPropValue)
softly.assertAll()
}
}In the examples you can see different ways to run the assertion.
Try the Figaf DevOps Suite
You can start a free trial of the Figaf DevOps Suite on your own SAP CPI content.
I do hope that you see the functions and can see how much it can improve your usage of SAP CPI.
We are improving the functionality over time, so it will be easier to manage your SAP CPI system.
