Testing translations

A translation table is only as good as its worst row, and the worst row is usually the one nobody tested: a code that isn't in the table. Testing translations means proving every entry in both directions, proving what happens when there is no entry, and proving that the content in production is the content you tested.

Decide the not-found behavior first

The Value Mapping function asks what to do when a value isn't found: pass the key through, use a default, or throw an exception. Each is right somewhere. Pass-through suits codes both sides share in most cases, but it is exactly how Contoso's untranslated PCE reached a supplier. A default suits optional data with a safe fallback. An exception stops the message, which is right when a wrong value costs more than a delayed message: units, plants, tax codes. Write the decision down per table, with the business owner's name.

Pass the key throughShared codes, rare unknowns, little harm

Default valueOptional data with a safe fallback the business accepts

Throw an exception, monitor closelyRare unknowns, but wrong values are expensive

Throw an exception and fix the sourceFrequent unknowns with high cost: the master data process is broken

Choosing the not-found behavior: weigh the cost of a wrong value against how often unknowns occur.

The Sign-Off Table · thesignofftable.com/academy/sap-pim-204

A test set for one table

Case	Example (CMC_UNIT_CODES)	Expected
Every entry, forward	PCE → EA, KGM → KG	Each target value
Every entry, reverse	EA → PCE	The default value where targets repeat
Unknown value	XYZ	The agreed behavior: key, default or exception
Empty value	Unit field missing or empty	Defined behavior, not a silent blank
Case and spaces	pce, "PCE "	Decide: values are matched exactly, so normalize first or fail
Wrong agency or identifier in the call	Mapping calls CMC_S4 / UOM instead of UNIT	Caught in test: every value comes back unmapped

Minimum test cases for a value mapping, from each entry to the misconfigured call.

The last row is easy to miss. If a mapping calls the table with a typo in the agency or identifier, every lookup fails, and with pass-through every value goes out untranslated. Only a test that checks a translated value, not just a successful message, catches it.

Prove the deployed content

Design-time content isn't runtime content. A saved but undeployed change has no effect, and a configured value in CMC_PROD can differ from CMC_TEST on purpose. Before go-live of each migrated interface, Contoso reads the deployed value mappings through the OData API in both tenants and compares them. Every difference must be one of the documented, configured exceptions.

Reconciling value mapping content between tenants: every difference is either a documented configured value or a defect.

The Sign-Off Table · thesignofftable.com/academy/sap-pim-204

Who tests what

Translation testing splits cleanly between roles. The integration team proves the mechanics: the call uses the right agency and identifier, both directions work, and the not-found behavior is what was configured. The business owner proves the content: that DET really is Great Lakes' code for Detroit, and that EA is what Lakeside expects for pieces. Priya's test cases name both, because a perfect lookup of a wrong code is still a wrong order. For partner codes, the final proof is the connected test with the partner, where the partner confirms that the translated values arrived as agreed.

Regression after every content change

Value mappings change more often than flows, and a content change is a release. Keep the table's test set as data, not as manual steps, so it can run after every import, configuration or edit. Contoso's rule: a change to a shared table reruns the translation tests of every interface that reads it, because a code that is right for Lakeside's 850 can be wrong for Great Lakes' 810. The integration flows don't change, but what they send does.

Hands-on lab · ACCELQ

Data-drive a value mapping test through an iFlow endpoint

One REST call, many rows: you'll parameterize the request with an Action parameter and let Test Cases supply each unit code, so every table entry and the unknown value run as separate test cases.

Practice on Your own SAP Integration Suite trial (SAP BTP trial, Cloud Integration capability) with a small flow and value mapping you build for this lab. Never a company tenant.

If you haven't set up ACCELQ yet, do the setup lab first. In your trial, create a value mapping CMC_UNIT_CODES with CMC_S4|UNIT to X12|UNIT and the pairs PCE/EA and KGM/KG, and deploy it. Build a flow: HTTPS sender /cmc/vm-unit (CSRF Protected cleared), a message mapping that sends Unit through the Value Mapping function with Throw Exception for unknown values, then an XML to JSON Converter. Deploy.
Prepare the encrypted Authorization value from your integration-flow service key as in the earlier REST labs (Base64 of clientid:clientsecret, encrypted under Resources > Utilities > Encrypt Text).
Create a Library Action Translate unit with input parameters endpointUrl, unitCode and expectedUnit. Insert a REST call (POST, Content-Type: application/xml, encrypted Authorization). In the payload's Text view write <Item><Unit>, type {{$ to pick unitCode, and close the tags.
Send once with PCE, assert status 200, click the returned unit value to create the assertion, and save. In the generated verify statement, click the expected value and link it to expectedUnit with the parameterization icon. If your build doesn't offer that on this statement, create one REST call per row instead.
Create a Scenario with the Action and open its Test Cases tab. Add rows: PCE/EA, KGM/KG, and a row for XYZ in a separate negative Action that asserts the error status your flow returns.
Run the Scenario on your Local Agent and open the Test Report: one test case per row.

Done when Every known code returns its translation and the unknown code fails with the status you recorded. Keep the report as evidence for the table, and rerun it after every change to the value mapping's content.

Learn more in ACCELQ’s docs: Working with Test Cases in ACCELQ · Power Up Your API Tests with Parameterization · REST API Test Automation in ACCELQ

Start the free ACCELQ trial Matt Angerer, who runs The Sign-Off Table, works at ACCELQ. Disclosure

Key points