What product/components do you use and which version/fix level?
webMethods 10.5
Are you using a free trial or a product with a customer license?
A customer license.
What are trying to achieve? Please describe in detail.
Good morning, probably this is something quite simple but I’m not getting it.
With a loop I’m trying to iterate over an array List
Then I want to grab the requestId which is in base64 format and convert it to Bytes so then I can in the next step convert those bytes to String using another loop.
are you sure that the requestId is a base64 encoded field?
If I remember right the “64” at the field icon stands for a long integer number (64Bit length) while “32” would indicate a regular integer with 32Bit of length.
A Base64 encoded field should be indicated as a String with additional constraints on it to limit its content to base64 encoded data.
Additionally, in your first screenshot the field is indicated as 64, but in the 3rd screenshot it is indicated as a String.
If this is the case you are passing an empty (non existent) string to base64Decode and not the long integer from the first screenshot.
You can introspect the type of each field by right clicking on it and select “Properties”.
Parts of these informations will also be visible in the Properties Panel when the field is just selected by a simple left click.
Can you share the complete outline of your service as well as structure samples of the document types being used?
You can add some comments to the map steps before that, i.e. indicating which transformer is used for what purpose.
This will help us in the analysis what might be the exact issue.
Just so we’re on the same page, you mention “using another loop”, but you’re really only using one LOOP, right? I believe you are, based on the screenshot, but I wanted to confirm.
You also mentioned something about “It blows reporting the error below,” but I don’t see an error in your post. What error are you receiving?
While I wait for your reply, a few quick suggestions:
Converting a base-64 string into a regular, unencoded string is not that uncommon, so I suggest creating your own base64Decode utility service that takes a string as input and returns a string as output. Put that service in your utilities package and call that service instead any time you come across this requirement. This utility service will also make it easier for you to specific scenarios. For example, with this utility service created, simply grab a sample input base-64 string and feed it to the utility service: do you get the expected output? If so, then you’re ready to work on the main service with the LOOP.
Make sure you know the encoding that was used on the source when the string was base-64 encoded, otherwise the services will assume the system’s default encoding, which is typically UTF-8 on *nix systems. Supply the necessary encoding as an input into the services.
Since you’re looping over a list and you’re trying to generate an output list, be sure to set the Output Array property of the LOOP step. In your case, it looks like that property should be set to result
I think Holger has the right idea. A base64-encoded string is going to be in a string variable and look something like this:
MTIzNA==
(this is the string “1234” run through pub.string:base64Encode in webMethods 10.5)
If you’re seeing a box with “64” in it for the requestID variable, you have a long integer data type (64-bit integer). webMethods won’t map that directly to a string variable, but you can feed it into the pub.string:objectToString service to get the string value out (this is the equivalent of the Java “.toString()” method that’s on every class). I think this is what you need to do instead of pub.string:base64Decode in your first screenshot. You shouldn’t need the pub.string:bytesToString call.
I’m with @Holger_von_Thomsen and @erossing.26610 here – a requestId being base64 encoded is highly unlikely. I’ve never seen a case where a string is base64 encoded.
The screen shots are showing design time declarations, where requestId is a string but at run-time is that really what it is? Is it as @Holger_von_Thomsen suggests really a Long (64-bit)? Is this data coming from a JSON payload? If so, the built-in parser creates Long objects from JSON fields that are number data type (unfortunate that it does this but that’s another discussion). Perhaps that is the case here?
I managed to solve this problem yesterday in the morning.
All of you are +/- closer.
Let me explain this. After receiving the JSON PAYLOAD.
I’m using a built-in-service called: pub.json:jsonStreamToDocument to convert it. Official Documentation
So, what it does ?: It Converts content from the JSON content stream to a document (an IData object). This service loads the whole JSON data into memory and then converts to an IData object.
In this case, we are talking about an array of objects, but when seeing the variable ate run time it is shown like this.
And everyone here in the office was thinking that it was a based64 string. But a based64 Variable has this format MTIzNA==, as it was mentioned by Evelyn.
Then I realized that this must be an Object Variable and I used another built-in-service called pub.string:objectToString and while looping the data I mapped the object to a String Variable.
Final Result:
Thank’s to you all for the support.
I hope this topic can help more people in the future.
That sounds like a bug, could you raise a defect ?
In the October 10.15 release we will be providing an alternative service pub.json.jsonToDocument, which avoid all the attempts to automatically convert the json content. Instead it will just treat everything as String, which should simplify all these issues with having to convert values.
The service will only attempt to strongly type content if you specify an optional document type.
regards,
John.
I don’t know how to do it. I just started with webMethods. Can you share the link with me?
I also can search for it, but only later… Now I’m underwater with work
He shouldn’t be getting Object types in the document from jsonStreamToDocument.
@a1user , don’t worry about reporting the issue if you are too busy. However, for future reference here is the link as I’m sure it will be of use to you in the future.
I don’t believe it’s a bug either. At least in my experience, whole numbers in JSON are always converted to a long in webMethods when the JSON object is converted to a document.
I believe that the base64 idea was, at the outset, an incorrect interpretation of what the
icon in the pub.json:jsonStringToDocument results meant. It was never a base64 string of any sort. It was always a number that pub.json:jsonStringToDocument presented as an object of java type Long.
jsonStreamToDocument turns anything that is not a string in the JSON to a corresponding object: Long, Boolean, Float/Double. Isn’t the ability to NOT do this and treat everything as string coming in 10.15 as you described?
As @Percio_Castro1 and @erossing.26610 have noted, there was a misunderstanding of the 64 icon. There was never any base64 anything involved here.
