Skip to main content
FromNine
Menu

Engineering

Integrations that move your data and tell you the moment they stall.

We link ERP, CRM, case systems and public platforms such as MyInvois through explicit contracts, events and sound identity. Data arrives where it should, failures surface on a dashboard instead of in a customer complaint, and new consumers, AI agents among them, connect without risk to the rest.

For Malaysian organisations that connect ERP, partners and public platforms at home, and often group companies or buyers in the EU.

Arrange a discussionConnected platforms
Integrations & APIs: the four layersFour layers, read downwards: consumers such as portals, apps and AI agents; an API gateway that checks identity; an event backbone; and, at the base, the systems of record that own the data.01Portals, apps and AI agents02Gateway with identity checks03Event backbone04Systems that own the data
  1. 01Contracts written first, in OpenAPI or AsyncAPI, then versioned and published
  2. 02Events that survive duplicates and disorder, with dead-letter queues and replay
  3. 03End-to-end monitoring per flow, and a named team behind every error queue

01 Common problems

Why organisations call us about integration

  1. 01

    A web of direct links that no one will touch

    Dozens of one-to-one connections tie ERP, CRM and in-house systems together. Renaming one field means retesting ten interfaces.

  2. 02

    Double orders and messages that vanish

    A retry books the same order twice. A failed message disappears without trace. Customers notice before the business does.

  3. 03

    Every new channel restarts the integration work

    Portal, mobile app and the new AI assistant need identical data, yet each was given a separate extract of its own.

  4. 04

    Tax and government platforms each become a project

    Sending e-Invoices to MyInvois, joining the Peppol network or connecting to a public service in another country takes months of security and onboarding work, every time.

02 Scope of the service

What the service covers

  1. 01 API strategy and API management

    APIs designed contract first with OpenAPI and AsyncAPI, a versioning policy, a gateway that enforces it and a developer portal where teams can find what already exists and reuse it.

    Activities

    • A map of current APIs and their owners
    • Design guidelines and a review routine
    • Gateway policies covering security, quotas and version rules
    • Searchable catalogue in a self-service portal

    What you would receive

    • API guidelines your teams have adopted
    • Gateway settings kept as code
    • A catalogue of documented APIs

  2. 02 Integration driven by events

    Message brokers, change data capture and the outbox pattern, plus the details that decide whether it all holds: ordering, consumers that tolerate repeats, dead-letter handling and replay.

    Activities

    • An event model with naming conventions
    • Outbox and change data capture on source systems
    • Consumers that tolerate repeats, and guarantees on ordering
    • Parking queues for failed messages, plus replay tooling

    What you would receive

    • An event backbone running in production
    • A schema registry with compatibility rules
    • A runbook for replay and recovery

  3. 03 Integration platforms, picked flow by flow

    SAP Integration Suite, MuleSoft and the integration services of the cloud providers all have uses. We tell you openly where an iPaaS outperforms custom code, and where it falls behind.

    Activities

    • Stock-take of existing middleware
    • Choosing a platform on lifetime cost
    • Mappings and connectors built for reuse
    • Migration away from ageing middleware

    What you would receive

    • Decision record explaining the platform choice
    • A library of integration patterns
    • A migration plan for current interfaces

  4. 04 Identity and trust between systems

    OAuth 2.0 and OpenID Connect, mutual TLS and identities for services, and login with MyDigital ID, the Malaysian national digital identity, for public-facing services. For group companies in the EU we also connect national eID schemes such as itsme, DigiD, BundID, FranceConnect and SPID.

    Activities

    • One identity model covering staff, citizens and machines
    • Token design, scopes and consent
    • Support with eID onboarding and certification
    • Groundwork for the EU wallets under eIDAS 2

    What you would receive

    • Threat-modelled identity design
    • Digital identity login running in production
    • Service identities with rotation of secrets

  5. 05 MyInvois, Peppol and public platforms

    Direct integration with the MyInvois API of the Inland Revenue Board of Malaysia (IRBM) to submit e-Invoices and receive validation results, or submission through a Peppol service provider using Malaysia PINT, the specification published by the Malaysia Digital Economy Corporation (MDEC) as Peppol Authority. For EU subsidiaries we connect national e-invoicing networks and data-exchange platforms in the same way.

    Activities

    • Mapping ERP invoice data to the e-Invoice structure and Malaysia PINT
    • Submission, validation results and resubmission through the MyInvois API
    • Onboarding with a Peppol service provider for buyers in Malaysia and in the EU
    • Security, logging and certificate handling for each channel

    What you would receive

    • A working connection to MyInvois or to a Peppol service provider
    • Mapping documentation for every document type
    • Operating procedures for rejections and resubmissions

  6. 06 Operational visibility for the business

    Flow monitoring written in the language of the business, cross-system reconciliation, and error queues cleared by the team that owns them.

    Activities

    • Flow monitoring in business terms
    • Reconciliation reports between systems
    • Classification and routing of errors
    • Alerts addressed to each flow owner

    What you would receive

    • Dashboard per business process, showing every flow
    • Reconciliation checks running in production
    • An ownership map covering every error queue

03 Architecture

A reference architecture, for illustration

Two routes leave each system of record. Calls that expect an answer go via system APIs and a gateway that verifies identity, scope and quota. Changes go out as events, captured by an outbox or by change data capture, and consumers are built so a duplicate does no harm.

A message that fails lands in a dead-letter queue from which it can be replayed, not in a log file nobody reads. A monitoring band shows each flow, from an order to an e-Invoice accepted by MyInvois, in terms the process owner understands.

Layers shown

Systems of record
ERP, CRM and case systems remain the source of truth for their data.
Request and reply
System APIs with version numbers, published through a gateway enforcing OAuth 2.0, mutual TLS and quotas.
Events
Outbox, message broker, dead-letter queue and integration-platform mappings.
Consumers
Portals, apps, AI agents, partners, MyInvois and Peppol, with digital identity login where members of the public sign in.
Illustrative example

  1. Systems of record

    • ERP, CRM, case management

  2. Request and reply

    • System-level APIs
    • Gateway: OAuth 2.0, mutual TLS, quotas

  3. Events

    • Outbox and change capture
    • Message broker
    • Dead-letter queue and replay
    • Mappings on the integration platform

  4. Consumers

    • Portals, apps and AI agents
    • MyInvois, Peppol and partner platforms
    • Identity: OIDC, mTLS, MyDigital ID

  5. Operations

    • Monitoring: flows, reconciliation, owned queues
APIs and an event backbone working side by side

For illustration only; this is not a system built for a client.

Read the diagram as text

Systems of record expose versioned system APIs, which an API gateway publishes to portals, apps and AI agents.

In parallel, an outbox and change data capture carry changes from the systems of record to an event broker. From the broker they reach MyInvois, a Peppol service provider and other partner or government platforms, and an integration platform that holds the mappings. Undeliverable messages wait in a dead-letter queue for replay. OAuth, mutual TLS and digital identity schemes secure every partner exchange.

Underneath runs a monitoring band: flow status, reconciliation outcomes and error queues, each queue tied to an owner.

04 Trade-offs and limits

Trade-offs we plan for

  • Exactly once comes from design, not from a setting

    What we do about it

    We expect messages to arrive twice or in the wrong order, and build consumers to cope, with keys and ordering rules settled for each event type.

    Limits and prerequisites

    Some older systems cannot take an idempotency key or report what they have processed. Around those we add reconciliation instead of pretending the problem away.

  • A platform is not the default answer

    What we do about it

    A platform pays off for standard connectors and mappings. Custom services pay off for complex logic, high volumes or tight latency. We record the reason for each integration.

    Limits and prerequisites

    Vendors revise their licence models. Today’s inexpensive platform may become tomorrow’s biggest integration cost, which is why our cost models span several years.

  • Tax and government platforms set their own timetable

    What we do about it

    Onboarding paperwork, security evidence and test plans are drafted early, and from week one we work alongside your Peppol service provider or whichever operator runs the platform.

    Limits and prerequisites

    Onboarding, certification and specification changes follow the operator’s timetable, not ours. We plan around it and show you where it sits on the critical path.

  • AI consumers get narrow APIs

    What we do about it

    Agents and assistants receive dedicated APIs with tight scopes, limits and audit logging, never the broad access given to internal services.

    Limits and prerequisites

    Opening any API to an agent raises the risk. Each one passes a review with your security team before release.

05 Working method

Our working method

We untangle before we build, and no flow leaves our hands without an owner.

  1. 01

    Map every flow

    Each interface with its volume, its record of failures and its business owner.

    ResultIntegration landscape ranked by risk

  2. 02

    Agree the rules

    Guidelines for APIs, conventions for events, an identity model and a platform decision.

    ResultAgreed integration rules and decision records

  3. 03

    Migrate one flow at a time

    The riskiest flows go first, with reconciliation beside the old interface until both give the same figures.

    ResultFlows migrated, with reconciliation as proof

  4. 04

    Operate in the open

    A dashboard for every business process and an owner named for every error queue.

    ResultOwnership map of flows and dashboards

06 Human oversight

Where decisions stay with people

Flows run unattended day and night. Accountability for their failures stays with named people.

  • Each error queue has an owner

    Failed messages, including e-Invoices that fail validation, go to a team that answers for them, with context and a replay action, not to a shared log.

  • Breaking changes need consumer review

    API or event changes that break compatibility go through a review with the consumers before they are published.

  • Replays are a deliberate act

    Pushing messages again into a system of record, or resending a document to MyInvois, requires authorisation and leaves a log of the person and the reason.

07 Technology

Technology we use

Integration platforms
  • SAP Integration Suite
  • MuleSoft
  • Azure Integration Services
  • Integration tooling on AWS and Google Cloud
Events and streaming
  • Apache Kafka
  • RabbitMQ
  • Event brokers offered by the cloud providers
  • Debezium for change data capture
APIs
  • OpenAPI and AsyncAPI
  • API gateways with developer portals
  • GraphQL where it suits the use
  • Contract tests
Identity
  • OAuth 2.0 and OpenID Connect
  • Mutual TLS
  • Keycloak, or the identity service of your cloud
  • MyDigital ID and national eID schemes in the EU

These names reflect hands-on engineering work. Their inclusion does not mean that a vendor partners with or endorses FromNine.

08 Scenario

An illustrative scenario

Illustrative example

An ERP sending e-Invoices to MyInvois through the API

01Starting point
A distributor issues thousands of invoices a month from its ERP and uploads them to the MyInvois Portal in batches. Rejections come back days later, and finance corrects them by hand while customers wait for validated documents.
02What we would deliver
An integration that submits each e-Invoice through the MyInvois API as soon as it is posted, stores the validation result against the ERP document, routes rejections to an owned error queue, and sends invoices for EU buyers through a Peppol service provider from the same data.
03Decisions that stay with people
Finance owns the rejection queue and approves every correction and resubmission; the tax manager approves changes to the invoice mapping.
04How results would be tracked
Time from posting to validation, share of documents validated at the first attempt, and hours spent on rejections each month.

09 By industry

By industry

  • Public Sector & Government

    Login with MyDigital ID for public services, data exchange between agencies with complete logging, and integration layers that survive a change of supplier. Read more about our view of the public sector.

  • Manufacturing & Industry

    ERP, MES and supplier portals linked by events so that planning, production and service see the same picture, with e-Invoices to MyInvois issued from the same order data.

  • Financial Services

    Core banking, CRM and partner APIs for banks, insurers and takaful operators, tied together with strong identity, audit logs and reconciliation finance can rely on.

Malaysia

MyInvois, Peppol and the e-Invoice phases

The Inland Revenue Board of Malaysia (IRBM) made e-Invoice mandatory in four phases by annual turnover or revenue: from 1 August 2024 above RM100 million, from 1 January 2025 above RM25 million up to RM100 million, from 1 July 2025 above RM5 million up to RM25 million, and from 1 January 2026 up to RM5 million. Taxpayers with annual turnover or revenue of less than RM3,000,000 are exempt. Documents are validated through the MyInvois Portal or API. The Malaysia Digital Economy Corporation (MDEC) is the Peppol Authority for Malaysia and publishes Malaysia PINT, and IRBM recognises submission through a Peppol service provider as one option.

Many Malaysian groups also invoice EU buyers or run EU subsidiaries, where Peppol and national e-invoicing rules apply, and where EU Digital Identity Wallets arrive under eIDAS 2. We design integration layers in which MyInvois, Peppol and each national platform are adapters behind stable internal contracts, so one ERP feeds every channel and a new country means a new adapter, not a new system.

Questions on integrations and APIs

Should we buy an integration platform or write our own integrations?

Both, each for different flows. Standard connectors, mappings and onboarding of partners favour a platform. Flows with high volume, tight latency or heavy logic often favour custom services. We decide flow by flow and write down why.

Do you integrate SAP, Odoo and Salesforce?

Yes, often, with one another and with custom systems, MyInvois and Peppol. FromNine is a partner of all three (Salesforce Summit Partner, SAP Gold Partner, Odoo Gold Partner), so our integration engineers work next to platform specialists. Our SAP integration work shows how.

Is event-driven integration necessary?

Events help when several systems must react to the same change, or when release cycles need to be independent. For a simple request and reply between two systems, an API is often enough. Most landscapes use both.

How do we connect to MyInvois and to Peppol?

Since 1 January 2026 all four e-Invoice phases are in force; taxpayers with annual turnover or revenue of less than RM3,000,000 are exempt. Your ERP can submit through the MyInvois API, or through a Peppol service provider, which IRBM recognises as one way to submit. Malaysia PINT, published by MDEC, defines the Malaysian Peppol format, and the same Peppol service provider can also reach buyers in the EU. We help you choose a route, map your invoice data and handle rejections.

Our middleware is old. Must it go?

Not overnight. After mapping what it carries, we move the flows with the highest risk or cost first, and reconciliation keeps running until every migrated flow has shown it works.

Which interface fails you most often?

We will show how it could become observable, safe to retry and owned, and what extending that to your other interfaces would involve.

Arrange a discussionService assistance