Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Generic request batch job #4065

Open
pintify opened this issue Jun 28, 2024 · 9 comments
Open

Generic request batch job #4065

pintify opened this issue Jun 28, 2024 · 9 comments

Comments

@pintify
Copy link

pintify commented Jun 28, 2024

Is your feature request related to a problem? Please describe.

The batch job feature is one of the most powerful but the collection of tasks available are very short and any given user can deploy their own additions. I think that implementing the generic request, available already via API REST, in the batch job would be very useful.
@pintify
Copy link
Author

pintify commented Dec 16, 2024

Just to clarify, this is the request in the API REST I'm using nowadays. The purpose of this issue is to obtain the same functionality through Batch Job to schedule the request on devices currently disconnected.

imagen

@Agnul97
Copy link
Contributor

Agnul97 commented Dec 17, 2024

what about the "command execute" step for device jobs?

@pintify
Copy link
Author

pintify commented Dec 17, 2024

Considering Kura implementation, the command request is intended to run shell commands on the gateway, not execute a method on Kura itself. Even in a third party MQTT client, which we have used, the command request is very limited in the arguments in comparison to generic request, where you can send even files if coded properly. We have created some customized remote requests for an advanced management of the device which is a very powerful feature in Kura. However, without the possibility to execute such requests through batch jobs, the customization is partially invalidated as many of our devices connect to Kapua only from time to time, in order to save battery.

Additionally, the generic request would allow to support all current and future available requests in Kura, even if Kapua has not yet implemented those requests or the company is taking some time to update the platform. It seems like a good compatibility tool anyways.

@Agnul97
Copy link
Contributor

Agnul97 commented Dec 17, 2024

I think to have understood what you are saying. Let me clarify: you are asking to implement a way to send commands to kura for the ALL the possible methods/app that kura can support and not just the subset now present in the drop-down menu. The "command execute", in this context, is just one of those methods

@pintify
Copy link
Author

pintify commented Dec 17, 2024

Indeed, that's it. To define such job, the user would have to provide the method, app, version, resources and a full payload such as the Device Management - Request call, where you can actually invoke any method available in the end device:

imagen

@Agnul97
Copy link
Contributor

Agnul97 commented Dec 19, 2024

@pintify can you provide me an example XML of a request that you would like to send with the hypothetical job we are talking about? basically one that could be executed via /{scopeId}/devices/{deviceId}/requests API request. For example, the one example provided in the swagger doc. but with XML format (check that can be executed smoothly). I think I will be able to implement the feature and I need this XML to do some tests

@pintify
Copy link
Author

pintify commented Dec 20, 2024

Well I'm not sure on how to do it. It greatly depends on how the rest of the job service is built. Some options I'd propose are:

  • Use the same JSON format translated to XML: 
    <?xml version="1.0" encoding="UTF-8" ?>
<channel>
    <type>genericRequestChannel</type>
    <method>EXECUTE</method>
    <appName>CMD</appName>
    <version>V1</version>
    <resources>command</resources>
    <resources>other</resources>
</channel>
<payload>
    <metrics>
        <valueType>string</valueType>
        <value>sleep</value>
        <name>command.command</name>
    </metrics>
    <metrics>
        <valueType>string</valueType>
        <value>180</value>
        <name>command.argument</name>
    </metrics>
    <body>body_encoded_as_base64</body>
</payload>
  • Define the payload in the XML and the request basic info in the web form:
    Field Example
    method EXECUTE
    appName CMD
    version V1
    resources command,other 
    <?xml version="1.0" encoding="UTF-8" ?>
<metrics>
    <valueType>string</valueType>
    <value>sleep</value>
    <name>command.command</name>
</metrics>
<metrics>
    <valueType>string</valueType>
    <value>180</value>
    <name>command.argument</name>
</metrics>
<body>body_encoded_as_base64</body>

The first one has the advantage of being more compact. The second one feels a bit more aligned with the rest of the batch jobs so I think it will be easier to implement and probably also easier to use both in the web and the API REST (via the call POST /{scopeId}/jobs/{jobId}/steps).

But again, it depends on how the job service is built. I've checked the source but it's too complex for me to be certain.

@Agnul97
Copy link
Contributor

Agnul97 commented Dec 20, 2024 •
edited
Loading

I think to have understood the general logic behind jobs-api and maybe its just a work of conecting the present logic wiht a custom jbatch *processor.java for the "genericReauest" for device management calling the appropriate DeviceRequestManagementService. I'll work on it when possible

@pintify
Copy link
Author

pintify commented Dec 20, 2024

That's great, thank you very much @Agnul97 !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@pintify @Agnul97