I need to check that all three of the required files in a set have been FTP'd before doing further processing on them. If all three files for the previous day have not arrived by 08:00 I need to raise and alert to a support person to contact the supplier. (Event 1)
If all three files are there, I then check the totals equal the transactions and if not I discard all three files and raise an alert to a support person to contact the supplier (Event 2)
I have the BizTalk (2010) - SCOM Management Pack loaded and need to know if I can create a custom rule that will raise and event for SCOM to detect, upon which I need SCOM to send a scenario-specific email to a recipient (e.g. Event 1 - All Three Required Files not Available! // or // Event 2 - Sum of transactions cannot be reconciled with Totals File)
We have looked at creating a SQL table for the message event log and defining custom processes for each connection point but it is clumsy, and I was advised that the above manner could be achieved, letting SCOM handle the Alert sending based on Events being raised by the process in BizTalk even though they are more BUSINESS events than SERVICE events.
Please advise - we have been going round in circles with this for two or three weeks now.
SCOM doesn't have anything out of the box like you are describing.
I do think you are looking at custom work here as Nick has suggested.
Another option is BizTalk360 does offer this feature. It is called "Process Monitoring" but would require a software license.
One option would be to use Business Activity Monitoring (BAM) and raise alerts in there.
Related
You have a command/operation which means you both need to save something in database end send an event/message to another system. For example you have an OrderService and when a new order is created you want to publish an "OrderCreated"-event for another system/systems to react on (either direct message or using a message broker) and do something.
The easiest (and naive) implementation is to save in db and if successful then send message. But of course this is not bullet proof because the other service/message broker is down or your service crash before sending message.
One (and common?) solution is to implement "outbox pattern", i.e. instead of publish messages directly you save the message to an outbox table in your local database as part of your database transaction (in this example save to outbox table as well as order table) and have a different process (polling db or using change data capture) reading the outbox table and publish messages.
What is your solution to this dilemma, i.e. "update database and send message or do neither"? Note: I am not talking about using SAGAs (could be part of a SAGA though but this is next level).
I have in the past used different approaches:
"Do nothing", i.e just try to send the message and hope it will be sent. Which might be fine in some cases especially with a stable message broker running on same machine.
Using DTC (in my case MSDTC). Beside all the problem with DTC it might not work with your current solution.
Outbox pattern
Using an orchestrator which will retry process if you have not got a "completed" event.
In my current project it is not handled well IMO and I want to change it to be more resilient and self correcting. Sometimes when a service is calling another service and it fails the user might retry and it might work ok. But some operations might require out support to fix it (if it is even discovered).
ATM it is not a Microservice solution but rather two large (legacy) monoliths communicating and is running on same server but moving to a Microservice architecture in the near future and might run on multiple machines.
We are using a Code and if that code is used we want a report to automatically send out.
Sales Code (if this sales code is used send out report)
This is used for a check method to ensure that sales code is not used inproperly.
Not sure how to do do this in cognos.
Thanks in advance,
Nathan
Event Studio might be the way to go here.
Use IBM® Cognos® Event Studio to notify decision-makers in your organization of events as they happen, so that they can make timely and effective decisions.
You create agents that monitor your organization's data to detect occurrences of business events. An event is a situation that can affect the success of your business. An event is identified when specific items in your data achieve significant values. Specify the event condition, or a change in data, that is important to you. When an agent detects an event, it can perform tasks, such as sending an e-mail, adding information to the portal, and running reports.
https://www.ibm.com/support/knowledgecenter/en/SSEP7J_11.1.0/com.ibm.swg.ba.cognos.ug_cr_es.doc/c_event_studio.html
Azure notification hubs have a feature that allow for subscribing to various topics in a many to many relationship. (many devices to many declared topic strings)
Suppose I take these steps:
I send an iOS device a notification, "test 1".
The device goes offline.
I send "test 2"
I send "test 3".
The device comes back online.
APNS only sends "test 3". Test 2 was dropped
Not to mention that APNS will only notify the most recent event "Test 3", it can also drop additional alerts in iOS 11 if I exceed the 30 maximum per day.
One of the things I like about Azure Hub service, is that I can manage that subscription "state" in an external storage. Now however, it seems I have to track the subscriptions myself, rebuilding part of the Azure HUB architecture... archiving out the subscriptions, topics, etc so the device can query the server for all missing events.
Question
How do I reconcile the features of Azure Hub and topic subscription with the issue of dropped APNS pushes?
You're correct that there's nothing ANH (or you as a developer) could do about the dropped notifications because that's the way ANPS is designed. Which means that the solution to your problem would really depend on what kind of application you're building, the architecture and user scenarios you're targeting.
A couple of ideas I have in mind which may or may not works for you depending on what you're trying to do are:
Send a silent push to the topic once in a while that would trigger the app to query the server on whether something has been missed
If the nature of the app is such that people open it often anyway, then you could do a background check at the time they open the app
Of course, in both of these scenarios, you'll have to build some additional infrastructure on your end to keep track of which device received or missed certain notifications. One thing that might help you not to have to rebuild parts of the NH that are already there is using Pet Message Telemetry (PMT). I haven't experimented with dropped notifications, but hopefully, there's a way to tell a dropped vs delivered message apart using PMT (looks like Dropped value of the PnsErrorDetailsUri field is something similar to what you need). And having that might help you simplify and reduce the amount of data you need to keep on your end to be able to tell whether someone had missed a notification or not.
We are a large group of developers, working on a project. We recently switched to TeamCity for managing the build process. I would like every developer to get a notification of the build success or failure. Since most of the developers are unfamiliar with TeamCity, and are super busy anyway, I'm concerned that asking them to subscribe to the build result may take a long time.
My Question: Is there a way to subscribe on the behalf of others to get build notifications via email?
Create a group (Administration - User Management - Groups), assign users to the group and create a new notification rule (email, IDE notififications, Windows Tray - whatever you want) for the group (Group detail - Notification rules).
I've been studying a lot of the common ways that developers design/architect an application on domain driven design (Still trying to understand the concept as a whole). Some of the examples that I saw included the use of events via an event aggregator. I liked the concept because it truly keeps the different elements/domains of an application decoupled.
A concern that I have is: how do you rollback an operation in the case of an error?
For example:
Say I have an order application that has to save an order to the database and also save a copy of the order as a pdf to a CMS. The application fires an event that a new order has been created and the pdf service that subscribes to this event saves the pdf. Meanwhile when committing the order changes to the database an exception is thrown. The problem is that the pdf has been saved but their isn't a matching database record.
Should I cache the previously handled events and fire a new error event that looks to the cache for "undo" operations? Use something like the command pattern for this?
Or... is the event aggregator not a good pattern for this.
Edit
I'm starting to think that maybe events should be used for less "mission critical" items, such as emailing and logging.
My initial thought was to limit dependencies by using the event aggregator pattern.
You want the event to be committed in the same transaction as the operation on your database.
In this particular scenario, you can push the event on a queue, which enlists in your transaction, so that the event will never go out unless the aggregate is persisted. This will make creating the PDF eventual consistent; if creating the PDF fails, you can fix the problem, and have it automatically retried.
Maybe you can get more inspiration in one of my previous posts on eventual consistent domain events with RavenDB and IronMQ.
Handling an event before it actually happened (committed) only works if the event handler participates in the transaction. Make the event handler transactional (for instance by storing the PDF in a database), or publish and handle events after the transaction committed.