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 ie. 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 engswee.yeoh has created a number of blogs on how to test SAP CPI.
You will need some boiler plate code to setup 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 mock some parts of the running may not be 100% if you use some exotic functions. That is why you still should be testing in real CPI.
In one of the coming releases, we will also be adding mesageFactory to test the attachments that you have created.
The only thing you need to do is to add the SAP CPI jars you can download here.
Last week we released a version of Figaf IRT 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 Figaf IRT 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 Figaf IRT to create automated assertions of all the parameters in the message.
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 it would be wise only to 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.
I think this approach will make it a lot easier to set up testing and run a set of assertions. As 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.
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.
In the examples you can see different ways to run the assertion.
There is a community version of Figaf IRT that allows you to run the application in single-user and with some limitations, but all of this should be working. It is all free.
I do hope that you see the functions and can see how much it can improve your usage of SAP CPI and want to buy the full package.
We are improving the functionality over time, so it will be easier to manage your SAP CPI system.
There are a number of different blogs on how to make it possible. I think engswee.yeoh has created a number of blogs on how to test SAP CPI.
You will need some boiler plate code to setup 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 mock some parts of the running may not be 100% if you use some exotic functions. That is why you still should be testing in real CPI.
In one of the coming releases, we will also be adding mesageFactory to test the attachments that you have created.
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 Figaf IRT 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 Figaf IRT 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 Figaf IRT 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 it would be wise only to 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. As 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 Figaf IRT
There is a community version of Figaf IRT that allows you to run the application in single-user and with some limitations, but all of this should be working. It is all free.
I do hope that you see the functions and can see how much it can improve your usage of SAP CPI and want to buy the full package.
We are improving the functionality over time, so it will be easier to manage your SAP CPI system.
- SAP Managed Tags:
4 Comments
