Middleware DE, Journal Export
AndreasEntscheffPinter opened this issue · 8 comments
I would like to use the functionality that's partly described here:
https://github.com/fiskaltrust/interface-doc/blob/8985e2a18651744a468aed5a6c197af9b2aa907e/doc/appendix-de-kassensichv/reference-tables/type-of-journal-ftjournaltype.md
So my aim is to run the journal functionality and get the DSFinV-K export as .ZIP file.
I'm using fiskaltrusts bring-your-own-datacenter method, so my middleware is running in a kubernetes cluster at google cloud. It's working fine, I sucessfully created a start-receipt, signed a few other receipts and received the expected signatures.
I expected that if I run a GET request to this URL it will work ({{base_url}} contains "http://" + the public IP of the middleware container) :
{{base_url}}/json/v1/Journal?type=4919338167972134914
But I only get the following response:
{
"type": "https://tools.ietf.org/html/rfc7231#section-6.5.13",
"title": "Unsupported Media Type",
"status": 415,
"traceId": "00-6be61ee6ef6d804d8fb9c4ec0d48c1a8-66a6472629346d4e-00"
}
4919338167972134914 is the decimal representation of 0x4445000000000002.
I tried a few variants of the path, but they all produce the same response, for example:
{{base_url}}/json/v1/Journal?type=4445000000000002
{{base_url}}/json/v1/Journal?type=0x4445000000000002
{{base_url}}/json/v1/Journal?ftJournalType=0x4445000000000002
{{base_url}}/json/v1/Journal?ftJournalType=4919338167972134914
What do I have to do to get the DSFinV-K export as .ZIP file? Am I maybe using an outdated version of the middleware? Running {{base_url}}/api/version tells me:
[
"fiskaltrust.SignatureCloud.DE",
"1.0.0",
"api:v1"
]
Hi @AndreasEntscheffPinter,
thanks for reaching out and adding all these details!
I think the issue is that you're using a GET request, but the Journal endpoint requires POST. Personally, I'm also not very happy with this API design, but it's of course hard to change it afterwards (as the BYODC should serve the same API as the 'normal' middleware). Could you retry the request with POST? Also, you should be able to use the Swagger endpoint to get the full API description, as described here.
I'll also move this issue to the BYODC repository, I think it fits fetter there. 🙂
@TSchmiedlechner
Thank you very much for your reply! I was actually already using POST but the issue was, that I didn't use the correct POST body (I left it empty).
Your comment about the swagger endpoint was the helpful hint for me: I found the description of the POST body to use there and used this, now I get at least a response that makes sense a bit.
I'm saying "makes sense a bit" because I was expecting sort of a binary stream that represents a ZIP file. Here's a screenshot of what I get... Am I doing anything wrong here? Or is that "chunk" JSON a special sort of ZIP file?
Furthermore: I was expecting that I need to use the decimal representation of 0x4445000000000002 as ftJournalType, that would be 4919338167972134914. But if I use this I get a 500 internal server error as response.
Please let me know, if I use the correct ftJournalType and how to handle the journal-response properly (is it a ZIP file or what is this?)
Hi @AndreasEntscheffPinter,
sorry for the late response, I somehow completely missed the notification. Great that my answer helped at least a bit.
You are using it correctly now. After quickly checking the code, it looks like we implemented the Journal function with the same method signature as we use it in gRPC (which also leads to the requirement of sending the type in the body instead of the request parameters). I agree that this is not really optimal - it would be nicer to just receive the raw data back instead of this JournalResponse array, like in the "normal" Middleware. We will re-discuss this behavior internally and let you know if there will be any other option.
I assume that the 500 is due to some weird serialization problems with JSON numbers larger than int32 - another reason to support calling this via GET-Parameters, I think. Anyway, we will investigate this, thanks for the hint.
Meanwhile, you can still use the response you're receiving; the content of these Chunk sub-arrays is the binary content of the file (so the response is basically an array of chunks of a byte array). Hence, if you concatenate all of them, you should receive a valid .zip file.
Sorry for the inconvenience, I again hope this helps.
Hello @TSchmiedlechner ,
Thanks for your reply 🙂
Meanwhile, you can still use the response you're receiving; the content of these Chunk sub-arrays is the binary content of the file (so the response is basically an array of chunks of a byte array). Hence, if you concatenate all of them, you should receive a valid .zip file.
I converted the byte-array to a string and saved it to a file named myfile.zip (I did exactly the same request as already shown in the screenshot from my last comment). When I tried opening myfile.zip windows complained, that it's not a valid zip file. So I tried opening the file in a text-editor and was expecting the usual funny characters you have in binary files. But what I see is this:
{"Assembly":"fiskaltrust.Middleware.Queue, Version=1.3.1.0, Culture=neutral, PublicKeyToken=null","Version":"1.3.1.0"}
This is not a zip file... Am I missing something?
Here is the chunkarray.txt and the result if you convert the byte-array to a file: myfile.zip. You shouldn't double-click that zip file after downloading, but open it in a text-editor.
Hi! This is the default data returned by the Middleware in case it cannot parse the ftJournalType, so I guess that sending the data as hex value is probably not working as we hoped.
We'll investigate why sending the type as a decimal number doesn't work in the next days and get back to you here when the issue is resolved. Meanwhile, sorry for the time you had to put into this issue.
Thank you @TSchmiedlechner 🙂
Hi @AndreasEntscheffPinter,
not sure if you were already informed via another channel, but just in case (or if somebody else finds this issue at a later point in time): version 1.3.12 of BYODC changed the behavior of the /journal endpoint, we now return a file stream. 🙂
Thank you @TSchmiedlechner 🙂