BRG-00 · Interoperability desk
Bridgeo Technologies LLC designs system integration, middleware, and platform interoperability for buyers who already run ERP ledgers, CRM records, WMS inventory, and accounting files — and need those platforms to exchange work without a second data entry desk.
BRG-01 · Stack
A typical Bridgeo route is a pale grid with four labeled rectangles — ERP, Message Bus, WMS, and File Drop — joined by arrows. Buyers specify those four hops; we wire protocol, retry, and payload shape between them.
ERP ledger, CRM records, WMS inventory, and accounting files are listed as live endpoints on the operations console, each with a status dot.
Synchronous REST or SOAP calls go through the API mapping studio. Asynchronous work lands on Orders.In, Inventory.Out, and Invoice.Ack queues.
Nightly extracts and trading-partner documents sit in the EDI/SFTP inbox as INV_2026.xml and ASN_004.edi until they are mapped.
Latency, last-run time, and result rows sit on the run monitor so operations can see a failed hop without opening four vendor screens.
BRG-02 · Modules
Each module is a screen buyers already recognize: mapping studio, queue board, file inbox, connector form, token log, and run monitor. No extra product families beyond these desks.
The mapping studio shows a JSON request on the left and SOAP XML on the right. Thin lines join orderId and customerCode so a REST caller can reach a SOAP ledger without rewriting either application. Sample payloads stay on the same screen.
The broker board lists those three queues with depth, consumers, and small depth graphs. Overview tiles for total messages, average latency, throughput, and consumers online sit above the list so warehouse and finance hops are visible at a glance.
The inbox is a file list: Filename, Standard, Size, Received. Invoice XML and ASN EDI rows carry Received or Mapped badges. Trading-partner drops stay in this list until the map desk consumes them.
Each connector is a form: Endpoint URL, Protocol (REST), Retry count, Timeout, plus logging toggles. The sidebar holds Connectors, Mappings, Logs, and Settings so a buyer can edit one hop without opening a second tool.
The transform monitor splits one order into two panes: JSON keys orderId and customerCode on the left, XML tags for the same fields on the right. Line numbers, tree view, and pretty-print stay on the editor chrome — the payload is the point.
The token desk logs Time, Client, Grant, and Result. Tabs cover OAuth 2.0, JWT, SAML, and LDAP. Client ID, token type, scope, and expiry sit in the detail pane when a hop must impersonate a system user rather than a person.
BRG-03 · Run control
After routes are live, the remaining screens are operational: nightly job list, message inspector, field dictionary, and latency board.
The scheduler lists those three jobs with Start, Duration, and Status. Success and Running are the two states on the board. Calendar view and a selected-job detail pane stay on the same screen so a missed extract is visible before the warehouse opens.
The inspector opens an order message: JSON body above, HTTP headers below, with Headers, Body, Raw, and Hex tabs. Status 200 OK is shown when the hop succeeded. This is the screen used to prove a field actually left the bus.
The dictionary is a table: Source Field, Source System, Target Field, Target System, Type. Search, filters, and export sit in the header. Transform notes (direct copy, lookup) stay in-row so finance and warehouse fields do not drift between releases.
The watch board pairs a latency line chart with a health-score donut and tiles for active routes, failed jobs, and average response. The table underneath lists each route’s last run, latency in milliseconds, and result so a stalled queue is not mistaken for a quiet night.
BRG-04 · Line sheet
Packages are sold as integration work, not boxed appliances. The table is the buying file: desk, artifacts, and the screen the operator lives on.
| Desk | Primary screen | Typical hop | Operator artifact | Packaging |
|---|---|---|---|---|
| Connect | API mapping studio; connector form | REST caller to SOAP ledger | Field lines for orderId, customerCode | Route definition + endpoint record |
| Bus | Queue board Orders.In / Inventory.Out / Invoice.Ack | Async warehouse and invoice events | Depth, consumers, throughput tiles | Queue names + retry policy |
| Map | JSON/XML split; field dictionary | ERP order to WMS and CRM code to accounting | Type and transform columns | Dictionary export |
| Exchange | EDI/SFTP inbox | INV_2026.xml, ASN_004.edi | Received / Mapped badges | Partner mailbox + standard |
| Directory | Token exchange log | OAuth, JWT, SAML, LDAP system users | Grant, scope, expiry | Client record, no end-user login product |
| Watch | Scheduler + run monitor + payload inspector | Nightly ERP extract, WMS push, invoice drop | Latency ms, last run, 200 OK body | Job list + alert on Failed |
BRG-05 · Sheridan bench
Work is staged at 229 W 10th St: a 19-inch rack for switches and 1U servers, and an oak workbench with two monitors — job table on the left, JSON/XML transform on the right.
Routes are built against the buyer’s ERP, CRM, WMS, and accounting endpoints. We do not host a public marketplace and we do not sell a consumer login. The Sheridan rack is for lab and outbound staging; production brokers and gateways run in the environment the buyer names on the work order.
BRG-06 · Buying notes
These notes match the screens above. If a question is not on this list, it is because the desk does not do that work.
No. The catalog is integration work packages: Connect, Bus, Map, Exchange, Directory, and Watch, delivered as route definitions, dictionaries, and operator screens.
ERP Ledger, CRM Records, WMS Inventory, and Accounting Files. Other systems are added only when they are named on the work order and given an endpoint record.
No. Tokens are system-to-system (OAuth, JWT, SAML, LDAP). There is no storefront and no end-user shopping cart.
The inbox is built for documents such as INV_2026.xml and ASN_004.edi over SFTP or EDI. Unmapped rows stay Received until the map desk consumes them.
Orders.In, Inventory.Out, and Invoice.Ack. Additional queues are created only when a route canvas adds a hop that those three names cannot cover.
The scheduler’s default trio is Nightly ERP extract, WMS inventory push, and Invoice file drop. Status on the board is Success or Running; Failed is the alert state on Watch.
BRG-07 · Photo file
Each still is embedded in this HTML file. Click to download the JPEG — no external image host and no separate folder required.