Using the Version 1 Data Access Extension SDK – SAP Lumira

Developer Tips

xyz is an invalid token?

Please ensure all the debug statements that print to the output stream are commented before testing the extension. Since the extension works by writing to the output stream, debug statements in code that also write to the output stream can interfere and result in errors like xyz is an invalid token. Whenever you see this error message while working with a extension, please check whether the all the debug statements are commented or not.

The SDK comes with a nifty utility, DAExtensionsTest.exe, which tests all the modes and generates a log file along with the data outputs of various modes into a csv. This tool is really helpful once the extension is finished and we need to do quick checks whether all the modes work or not. But while developing an extension, we need a better view of how various parameters are being stored inside Lumira. We can use a simple hack in our code to do this. A debug flag can be used to switch to a special debug mode in our code. When the debug flag is true, instead of writing actual data in the data block, we can create a table and write all the parameters that Lumira stores. This allows us to create a document where we can look at the parameters that Lumira is supplying the extension for the Edit and Refresh modes. Using a debug flag in our code will allow us to make quick checks whenever we want to look at the connection parameters getting stored inside Lumira.

What’s up with my parameter values?

The SDK uses ; as a separator to store parameter names and their values in the form of name;value;true/false. The boolean flag is usually set to true to write the parameters being supplied to the DSInfo store. A parameter is not stored or used by Lumira if the flag is false The value of a parameter could itself be boolean though. The SDK then parses each line between beginDSInfo and endDSInfo and stores the name value pairs. Lumira automatically converts the first semicolon to = and reads the value until the next semi-colon. It then stores the parameter with the format name=value; Hence, we write and parse parameters and their values in different ways.

I have many lines to store in one parameter?

Another common issue you could encounter is storing multiple lines of information as a part of a single parameter. Since there is no way to do that with the SDK, we can do a quick hack ourselves by encoding the newline character while storing the parameters in Lumira and decoding them after reading them back from the store. A bullet-proof way is to implement a set of encoding and decoding functions to handle LF U+000A, CR U+000D and encode them into something like %0A and %0D or any pattern which has a less chance of occurring in the value of the parameter.

I also did a small test on all the special characters to see which ones the SDK has conflicts with. Semi-colon and double-quotes in the value field were breaking things too and the encode and decode functions are a good place to handle them as well.

Also, ensure the same parameter name is not used multiple times as Lumira will only store the last one that is sent and overwrite the previous ones sent with the same name.

A good tip to speed up development is to create a windows batch file early on to copy the executable to the target directory as it reduces the overall development time spent.

The extension I’ve created sends a set of http requests to a url endpoint to retrieve a JSON collection and sends it to Lumira. I’ve used Go as it had a good set of libraries to handle HTTP requests and JSON and it also compiles to an executable. It is some food for thought if you have a similar use case in mind.