feat: Add DataQueue class
Add a DataQueue class that can be called similar to the Java toolkit Experiment with pulling out API data into a const variable
PR opened to discuss work thus far and solicit input into how to improve pulling out these classes a la the Java Toolkit
I like the idea, and if we can strive to be more like the revered Java Toolbox, that's great. However, now that we have the *DATA_QUEUE* SQL services, this is much less necessary
https://www.ibm.com/support/pages/ibm-i-services-sql
A Data Queue class and associated java types is still good for usability, so I'm not opposed to this enhancement, but want to doc that the SQL path is a food fallback if someone needs such function before this class is completed.
:wave: Hi! This pull request has been marked stale due to inactivity. If no further activity occurs, it will automatically be closed.
I like the idea, and if we can strive to be more like the revered Java Toolbox, that's great. However, now that we have the
*DATA_QUEUE*SQL services, this is much less necessary https://www.ibm.com/support/pages/ibm-i-services-sql A Data Queue class and associated java types is still good for usability, so I'm not opposed to this enhancement, but want to doc that the SQL path is a food fallback if someone needs such function before this class is completed.
I'd like to see this class added since the SQL Data queue service aren't support on 7.2. Our upgrade is planned, but with the world as it it that may be delayed.
I have a LUG customer concerned about the deprecation of iDataQueue, I'm going to make sure this PR is up to date and refresh any questions I have, then it might be a good idea to throw some developer minutes/hours at it to get it landed.
Ok, I have tested the latest push:
Passing:
- Creating a
DataQueuewithnew DataQueueworks - Creating a DTAQ on the system with
createfunction works - Deleting a DTAQ on the system with
deletefunction works - Receiving data with
receiveworks - Sending data with
sendworks
Failing:
- When calling
receive, if you don't pass a length, it will try to callQMHQRDQDto get information about the DTAQ. I am not sure how to add the params correctly to get it to work... particularly the receiver variable,type: 'ds', and the like.
I see I have some linting failing, I might have disabled eslint on my VSCode at some point. Will reenable and ensure Linting and DCO bot are happy. No idea why GitHub Actions tests are failing, I think I haven't touched anything outside of my file.
Lingering questions:
- I see that
xmlToJsonwas deprecated, along with all of the other functions we had. I have adjusted the class to return XML, but it seems like it would be best to return JSON? Since this is the first helper(?) class, maybe we can talk about how to do that best. - I see that everything is returning callback functions, and I have emulated that behavior. It is possible to have functions use callbacks or Promises, similar to how I do in the
odbcpackage. Just check to see if a callback was passed as the final parameter, and if not, go to a Promise workflow. This would ensure API stability with anyone currently using the package, but would also allow developers to use the more modern Promise syntax.
Ok, I have tested the latest push:
Passing:
- Creating a
DataQueuewithnew DataQueueworks- Creating a DTAQ on the system with
createfunction works- Deleting a DTAQ on the system with
deletefunction works- Receiving data with
receiveworks- Sending data with
sendworksFailing:
- When calling
receive, if you don't pass a length, it will try to callQMHQRDQDto get information about the DTAQ. I am not sure how to add the params correctly to get it to work... particularly the receiver variable,type: 'ds', and the like.I see I have some linting failing, I might have disabled eslint on my VSCode at some point. Will reenable and ensure Linting and DCO bot are happy. No idea why GitHub Actions tests are failing, I think I haven't touched anything outside of my file.
Lingering questions:
- I see that
xmlToJsonwas deprecated, along with all of the other functions we had. I have adjusted the class to return XML, but it seems like it would be best to return JSON? Since this is the first helper(?) class, maybe we can talk about how to do that best.- I see that everything is returning callback functions, and I have emulated that behavior. It is possible to have functions use callbacks or Promises, similar to how I do in the
odbcpackage. Just check to see if a callback was passed as the final parameter, and if not, go to a Promise workflow. This would ensure API stability with anyone currently using the package, but would also allow developers to use the more modern Promise syntax.
Hey Mark....Regarding the lingering question on deprecated xmlToJson...If you have not figured it out by now :) use xml2js:
const { parseString } = require('xml2js');
connection.run((error, xmlOutput) => { if (error) { throw error; } parseString(xmlOutput, (parseError, result) => { if (parseError) { throw parseError; } console.log(JSON.stringify(result)); }); });_
Hope this helps.