We have to initially write a cron for whenever the solution has to be run. Currently, if the script has to run from Monday to Friday, we have to do some script. It would be easy if we had an option to select multiple things to run the script from Monday to Friday.
An Amazon EventBridge rule can be governed by only a single Cron expression. It would be good if the solution provided a feature to add multiple Cron expressions to one rule.
Cloud Architect at a transportation company with 10,001+ employees
Real User
Top 5
2023-03-17T12:52:50Z
Mar 17, 2023
Amazon EventBridge doesn't have the feature of event replay. Let's say a customer reports an issue, and you want to reproduce the error. There is no source or feature where you can click on a button or put in a query and then try to reproduce the problem on a dashboard. So there is no such mechanism for that. The only way to debug it is to pass that particular event again and make it live to reproduce. That's not the only feature we need. The second thing is about documentation, but they have improved it a lot now. They started it, but it still needs more improvement. They use open API specifications to document events, but Amazon EventBridge is an async model solution. Therefore, it should have async API documentation, not open API. Open API framework documentation works on rest methods like GET, POST, PUT, etc. However, EventBridge does not work with REST methods at all, and it works with a source and target mechanism or a publisher and subscriber model. So there is a channel, publisher, and subscriber it uses. And in open API, you don't find these things, and you can only find these things in the async API documentation. When you want to tell people about a particular model or schema that an event looks like, you write it in the documentation. Then, you can generate the code of the whole library. For example, if you want to consume an event, you can prepopulate the classes and functions, and developers can easily work on it. These features are available in async API but not in AWS. AWS provides the rest API, which requires a lot of customization. So I would say that's missing in the AWS cloud.
What is message-oriented middleware? Message-oriented middleware, or MOM, is a software infrastructure that allows applications to exchange messages or data between distributed systems. Essentially, middleware bridges any gaps between applications, databases, or other tools to deliver unified services for end-users. MOM is widely recognized as a promising solution for facilitating communications between heterogeneous systems without having to rebuild an organization’s IT infrastructure....
We have to initially write a cron for whenever the solution has to be run. Currently, if the script has to run from Monday to Friday, we have to do some script. It would be easy if we had an option to select multiple things to run the script from Monday to Friday.
An Amazon EventBridge rule can be governed by only a single Cron expression. It would be good if the solution provided a feature to add multiple Cron expressions to one rule.
Amazon EventBridge doesn't have the feature of event replay. Let's say a customer reports an issue, and you want to reproduce the error. There is no source or feature where you can click on a button or put in a query and then try to reproduce the problem on a dashboard. So there is no such mechanism for that. The only way to debug it is to pass that particular event again and make it live to reproduce. That's not the only feature we need. The second thing is about documentation, but they have improved it a lot now. They started it, but it still needs more improvement. They use open API specifications to document events, but Amazon EventBridge is an async model solution. Therefore, it should have async API documentation, not open API. Open API framework documentation works on rest methods like GET, POST, PUT, etc. However, EventBridge does not work with REST methods at all, and it works with a source and target mechanism or a publisher and subscriber model. So there is a channel, publisher, and subscriber it uses. And in open API, you don't find these things, and you can only find these things in the async API documentation. When you want to tell people about a particular model or schema that an event looks like, you write it in the documentation. Then, you can generate the code of the whole library. For example, if you want to consume an event, you can prepopulate the classes and functions, and developers can easily work on it. These features are available in async API but not in AWS. AWS provides the rest API, which requires a lot of customization. So I would say that's missing in the AWS cloud.