README
¶
OraPub
This project provides code to process events to publish in the Oracle event store, with hooks for adding processing functions to be invoked for each published event.
Usage
Packages that wish to process published events need to provide implementations
of the Initialize and Processor function types in an EventProcessor
structure, and register them with the package.
Once everything is registered, an OraPub instance can be instantiated,
its Connect method called, the processors initialized via the
InitializeProcessors method, then the event loop instantiated using
ProcessEvents.
The es-data-pub project performs all the steps needed to process published events. Using the es-data-pub project, all a packge needs to do for processing events is to import the event processing packages, register them if they don't register themselves in their package init methods, then invoke the es-data-pub ProcessEventMethod function.
Limitations
The current implementation doesn't have a clean way to shutdown the processing loop.
Event processing is done within a transaction, which is used to isolate the processing of events amidst concurrent event processors. The transaction does not extend to the event processors - if they return errors they will not get another shot at processing the event. Also, if an error occurs causing the transaction to rollback, it is possible the event processor could be invoked with the same event at a later time.
Dependencies
go get github.com/Sirupsen/logrus go get github.com/xtracdev/goes go get github.com/rjeczalik/pkgconfig/cmd/pkg-config go get github.com/mattn/go-oci8
Contributing
To contribute, you must certify you agree with the Developer Certificate of Origin
by signing your commits via git -s. To create a signature, configure your user name and email address in git.
Sign with your real name, do not use pseudonyms or submit anonymous commits.
In terms of workflow:
- For significant changes or improvement, create an issue before commencing work.
- Fork the respository, and create a branch for your edits.
- Add tests that cover your changes, unit tests for smaller changes, acceptance test for more significant functionality.
- Run gofmt on each file you change before committing your changes.
- Run golint on each file you change before committing your changes.
- Make sure all the tests pass before committing your changes.
- Commit your changes and issue a pull request.
License
(c) 2016 Fidelity Investments Licensed under the Apache License, Version 2.0
Documentation
¶
Index ¶
Constants ¶
This section is empty.
Variables ¶
var ErrNilEventProcessorField = errors.New("Registered event processor with one or more nil fields.")
var ErrNoEventProcessorsRegistered = errors.New("No event processors registered - exiting event processing loop")
var ErrNotConnected = errors.New("Not connected to database - call connect first")
Functions ¶
func ClearRegisteredEventProcessors ¶
func ClearRegisteredEventProcessors()
ClearRegisteredEventProcessors clears out the registered event processors. This is useful when testing.
func RegisterEventProcessor ¶
func RegisterEventProcessor(name string, eventProcessor EventProcessor) error
RegisterEventProcessor registers an event processor with OraPub. Event processors registered with OraPub are initialized then receive events when processing the events in the event table.
Types ¶
type EventProcessor ¶
type EventProcessor struct {
Initialize func(*sql.DB) error
Processor func(db *sql.DB, e *goes.Event) error
}
EventProcessor is implemented for hooking into the processing of the events in the event store publish table
type OraPub ¶
type OraPub struct {
LoopExitError error
// contains filtered or unexported fields
}
OraPub provides the ability to process the events in the event store publish table.
func (*OraPub) Connect ¶
Connect creates the database connection with the given connection string and max connection retrys.
func (*OraPub) InitializeProcessors ¶
InitializeProcessors initializes all the processors for registered event handlers.
func (*OraPub) ProcessEvents ¶
ProcessEvents processes the events in the publish table, sending each event to the registered event processors. Event processing is done within a transaction, which is used to isolate the processing of events amidst concurrent event processors. The transaction does not extend to the event processors - if they return errors they will not get another shot at processing the event. Also, if an error occurs causing the transaction to rollback, it is possible the event processor could be invoked with the same event at a later time.
Source Files
Directories