NATS - just one subscriber to take action for published event in a microservicearchitecture - message-queue

I'm new to NATS and have read all the examples for:
https://nats.io/documentation/concepts/nats-messaging/
I'm in Microservciearchitecture where in microservice-Y (MSY) need to store some information published from other microservice-X (MSX) I have 2-10 instances of MSY so when changes are made in MSX and MSX-instance publishes event I want that only 1 instance of MSY should save information so not all of them save the same data.
I have read Request-Repy:
https://nats.io/documentation/concepts/nats-req-rep/
but there seems that all of instances receives message (and will handle it) even if it is point-to-point and reply is handled just for the one instance that is quickest to reply
Is this correct or have I missunderstood example?
If I only need that 1 instance of MSY should handle given message (store data in db) what can I do to acheve this?

Use queue groups. If you have multiple subscriptions on the same subject with the same queue group, only one of the members of the group will receive the message.
Check this out: https://nats.io/documentation/concepts/nats-queueing/

Related

real-time notification if is not online

scenario: When user 1 assigns a user 2 to a task user 2 will receive a notıfication
how can I realize it?
do I have to store the notification in the database then send it to user2 then remove it after he sees it. but with this, I think he will need to refresh the page to get notified
,or there is any other logic to do it?
using:
nodejs mongoDb mongoose
I solve this problem by creating a notification schema with isSeen field (defaults to false) and the ObjectID of the notification. Once the user sees the notification, the isSeen property is put to true. Based on the isSeen status I'd apply active and inactive classes.

How to invoke Time Sheet Invoicing Upload SAP Fieldglass REST API call?

I'm looking into how to use the Time Sheet Invoicing Upload and first port of call was the Try It Out page.
The documentation lists the value for the mandatory "Type" field as TIMESHEET INVOICING but this seems at odds with other calls (it's usually just the call name, e.g. Time Sheet Invoicing Upload). Have tried these values and multiple other variants on the "Try It Out" page but all have failed so far with "The Type value specified in this file is not recognized".
Grateful for any pointers on how to get this working and/or advice on whether the SAP Fieldglass REST API documentation for this call might need to be amended.
As an aside - am also wondering about some of the fields listed in the body - e.g. TIMESHEET ID and ORIGINAL TIMESHEET ID are in block capitals, which doesn't follow the convention of other fields and the API reference for this call just has "data": [ {} ] in the body with no actual fields present - again, this is at odds with other calls.
Re: Main question - The documentation is incorrect - the Type value should be "Time Sheet Invoicing Upload". Also found out that this particular call can only be made by a Supplier tenant, not a Buyer tenant. In our case, we needed to request SAP to enable Configuration Manager for that tenant and then we could log in as the Supplier, change to the linked Configuration Manager account, create the API Application Key and License Key, enable the integration connector and use all of the above to authenticate as the Supplier and make the API call... it also requires a Buyer field in the header (set to the 4 digit Buyer code e.g. "A123") - this also isn't mentioned in the documentation.
Re: Aside - Turns out the API is case insensitive for field names - e.g. "Timesheet ID" will work just as well as "TIMESHEET ID".

AngularJS form wizard save progress

I have a service in AngularJS that generates all the steps needed, the current state of each step (done, current, show, etc) and an associated directive that actually implements the service and displays the data of the service. But, there are 2 steps that are divided in 4 and 3 steps each:
Step one
Discounts
Activities
Duration
Payment Length
Step two
Identification
Personal data
Payment
How can I "save" the state of my form in case the person leaves the site and comes back later? Is it safe to use localStorage? I'm no providing support for IE6 or 7. I thought of using cookies, but that can end up being weak (or not)
Either local storage or cookies should be fine. I doubt this will be an issue, but keep in mind that both have a size limit. Also, it goes without saying that the form state will only be restored if the user returns on the same browser, and without having deleted cookies / local storage.
Another option could be to save the information server side. If the user is signed in, you can make periodic AJAX calls with the data and store the state on the server. When the user finishes all steps, you can make an AJAX call telling the server to delete any saved data it might have. This allows you to restore state even if the user returns on a different browser, as long as he is signed in.
Regardless of what direction you go with this, you can use jQuery's serialize method to serialize the form into a string and save it using your choice of storage.

Stream Position Returned By Box API Cannot Be Used To Track Events

Thanks for your reply for my question: Is this a bug of Box API v2 when getting events
This is a new problem related to this. The problem is that I cannot reliably use the next_stream_position I got from previous calls to track events.
Given this scenario:
Given the following two GET HTTP queries:
1. GET https://api.box.com/2.0/events?stream_position=1336039062458
This one returns the JSON file which contains one file entry of myfile.pdf and the next stream position = 1336039062934
2. GET https://api.box.com/2.0/events?stream_position=1336039062934
This call uses the stream position I got from the first call. However, it returns the JSON contains the exactly same file entry of myfile.pdf with the first call.
I think if the first call gives a stream position, it should be used as a mark for that exact time (say: TIme A). If I use that stream position in subsequent queries, no events before "Time A" should be returned.
Is this a bug? Or did I use the API in the wrong way?
Many thanks.
Box’s /events endpoint is focused on delivering to you a highly reliable list of all the events relevant to your Box account. Events are registered against a time-sequenced list we call the stream_position. When you hit the /events API and pass in a stream_position we respond to you with the events that happened slightly before that stream position, up to the current stream_position, or the chunk_size, whichever is lesser. Due to timing lag and our preference to make sure you don’t miss some event, you may receive duplicate events when you call the /events API. You may also receive events that look like they are ‘before’ events that you’ve already received. Our philosophy is that it is better for you to know what has happened, than to be in the dark and miss something important.
Box events currently give you a window roughly 5 seconds into the past, so that you don't miss some event.
We have considered just delaying the events we send you by about 5 seconds and de-duplicating the events on our side, but at this point we've turned the dial more towards real-time. Let us know if you'd prefer a fully de-duped stream, that was slower.
For now, (in beta) if you write your client to check for duplicate events, and discard them, that will be best. We are about to add an event_id to the payload so you can de-duplicate on that. Until then, you'll have to look at a bunch of fields, depending on the event type... It's probably more challenging that it is worth.
In order to help you be able to figure out if an event is a duplicate, we have now added to each event an event_id that will be unique. It is our intention that the event_id will allow you to de-duplicate the responses you receive from subsequent GET /events calls.
You can see this reflected in the updated documentation here, including example payloads.

Is my logic for a .tell ( notification ) function on my IRC bot sound?

I have a bot in node.js and I'm wondering what logic I should use for a .tell function. The purpose of the function will be to give a message to users who are offline. So, if john was offline on freenode.net/#foo and I typed .tell john your mother was great last night, I want the bot to store this message and display it whenever john joins the channel.
If john is already in the channel, I want the bot to immediately just display the message.
I am already using mongodb as a database to store information, so I can probably store all my messages in there. Here's the logic I had in mind so far:
1. After user A types .tell john your mother was great, a listener will pickup the pattern /\.tell ([\w-]+) (.*)/ and store a variable for the message ( var msg, the user who posted the message ( var from ), and the name of the user to be messaged ( var to ). I will also have a global variable signifying the channel name and network of the server.
2. I'll store a row in mongodb such as:
to from message network channel delivered time
--------------------------------------------------------------------------------
john meder your mother was great freenode.net #foobar 0 (TS)
last night
3. Setup a listener for anyone joining a channel since the bot can live in multiple channels under one network, and detect if there any messages that are not delivered and if there are, attempt to match the to and network and channel to the stored messages, and if row(s) are found, display them.
This sounds ok, but can anyone review it and maybe offer advice? I'll be forced to have a listener listen for anyone entering any channel, right? There's no alternative to that?
This seems all fine. I don't see how you could not have a listener.
One thing I'd add is maybe a hash in the bot to keep track of who has pending messages. This way you won't be querying MongoDB every time someone joins a channel.
I.e.
messages = {};
messages['freenode.net'] = {};
messages['freenode.net']['john'] = 1;
Might be overkill, but if your monitoring a channel that has many JOINs, you might find yourself querying MongoDB a lot.
My two cents.
Christian