Most TYPO3 instances are operated in parallel with an ERP system. These two systems usually exist independently of each other for as long as possible: while one employee changes a price in the ERP, another has to re-enter the same price in the website, and a customer then notices the discrepancy. Connecting the two systems closes this gap, but the choice of the technical implementation defines whether the result is a reliable data source or a permanent source of support tickets.
This article explains what a TYPO3 and ERP integration can be used for, what alternatives exist for such an integration and what considerations should be made when designing such a project.
Connecting TYPO3 and an ERP – Use Cases
An integration is usually only worthwhile if it automates a process or provides information that previously had to be entered manually. Common use cases in medium-sized German companies are:
- Transfer of article data, prices, and stock levels from the ERP to the website
- Portals for registered users in which they can view their own orders, invoices, and delivery status
- Web forms and inquiries that are processed in the ERP or a connected CRM instead of being forwarded by e-mail
- Orders placed via the website that need to be transferred to the ERP for processing
A good question to ask here is where the data originates that is to be displayed or processed on the TYPO3 website. Usually, there is one system of record per data field: the ERP stores article numbers, prices, and tax categories, while descriptions, images, and texts are managed in TYPO3. Things get more complicated when fields exist in both systems, but no one is clearly responsible for their content.
Establishing Ownership of Fields
It is advisable to clarify this issue in writing before designing the technical implementation. A rough overview with fields, sources, and update intervals is usually sufficient for an initial planning.
As an example, consider a company that manufactures thousands of different parts and maintains a product catalog on its website. The ERP contains information on all components: technical descriptions, list prices, and stock levels. The website needs to display the same parts, but with marketing-oriented texts and additional documents. In this scenario, it is logical to have the ERP deliver the commercial data to TYPO3 via the integration, while the editors enrich the data with additional information in TYPO3. When it comes to the data fields that are transferred, only the fields that are actually intended for display should be updated, leaving out fields that contain information irrelevant to the website. Otherwise, there may be frustration if changes in TYPO3 are always silently overwritten by the next transfer from the ERP.
Alternatives in Connecting TYPO3 and an ERP
There is no universally superior approach to integrating TYPO3 and an ERP – the resources and requirements of the individual systems must be taken into account. The following options are available:
Direct API Calls
Many modern ERPs offer REST or OData APIs (SAP’s S/4HANA and Microsoft Dynamics are among them, although the exact technologies vary from system to system). These can be accessed directly from TYPO3, for example, from within a custom extension. This approach is ideal if the data needs to be as fresh as possible, as is the case with stock queries.
Direct API calls are usually only used for individual queries or for very simple data structures. If every request to the ERP takes several seconds, the TYPO3 website will become unusable. The alternative is to implement caching with a clearly defined timeout and, in the worst case, a static message if the ERP is unavailable for too long.
Scheduled Data Synchronization
For synchronizing large sets of data, such as product catalogs or price lists, a scheduled transfer is usually more resource-efficient. This means that TYPO3 connects to the ERP at regular intervals and transfers the updated data to its own database. It is then processed further from there, for example displayed on the website. This approach reduces the load on the ERP, but at the cost of increased latency.
For most companies, this is the preferred solution for product catalogs: the data is only as fresh as the interval between two updates, but a daily synchronization is usually sufficient for most use cases. For more dynamic data such as stock levels, this approach may not be suitable.
ERP Integration with Middleware
If a company uses a variety of systems (ERP, CRM, shop, PIM, payment gateway, …), it may make sense to set up middleware. This intermediate program is responsible for exchanging data between different systems. It can be useful if one of the systems does not have the required interfaces or if the company wants to reduce the coupling between its systems. TYPO3 only needs to communicate with the middleware, which in turn connects to the other systems. The main advantage of this approach is that changes on one side rarely affect the other. The complexity and potential points of failure increase, however, and the middleware must be maintained and monitored separately.
File Exchange
Many older ERP systems only offer limited digital interfaces. One option is to export the required data in CSV format at regular intervals and import it into TYPO3. This approach is particularly suitable if the ERP offers no other option. Files can be created manually or automatically and transferred to TYPO3 via webdav or similar protocols. It is important to design a standardized format and to check the files for errors before importing them. In addition, the import should be stopped in case of an error and the person responsible notified, for example via e-mail. It should also be noted that such a file exchange may require additional infrastructure if the ERP is not publicly accessible on the Internet.
Implementation in TYPO3
A distinction must be made between front-end and back-end in TYPO3 – the website itself is usually designed with TYPO3’s own HTML templates. However, it is also possible to customize existing templates or develop completely new ones. One thing to note is that most integrations are implemented as extensions, either existing ones or custom developments. In either case, it is a good idea to separate the logic of the data exchange from the presentation as much as possible. This way, a redesign of the website does not affect the data exchange.
A few general considerations are particularly important when developing such an extension:
- Store imported data in the TYPO3 database wherever possible so that it can be displayed, edited, and searched for later
- Use caching wherever possible to avoid overloading the ERP with unnecessary requests and to ensure that TYPO3 does not become slow itself
- Do not hard-code access data for the ERP in the extension – TYPO3 offers various ways to store this type of information in the configuration
- Log all error messages in a way that allows them to be evaluated and, if necessary, notify the responsible person
If the company has extensive TYPO3 expertise but only limited knowledge of the ERP, or the other way around, an external agency can be considered as an option. Softwareentwicklung in Berlin is a popular option for many businesses that want to accelerate development without tying up permanent staff. However, it is still essential to have someone in the company who understands both systems and can serve as the central contact for the TYPO3 ERP integration. This could be the Softwareentwicklung Outsourcing agency, or specialized consultants within the company.
Customer Portals and User Authentication
If customers are to be given access to their own orders or invoices, this requires particular attention in terms of security. TYPO3 has its own user administration, but it is likely that the ERP is the system of record for customer data. A distinction must be made between whether TYPO3 users are created in TYPO3 itself or whether they are managed in the ERP. There may also be a separate identity provider that handles user authentication.
In any case, it must be ensured that a user can only see their own data at all times. Particular care must be taken here with similar-looking customer numbers or company names that belong to different customers. Personal data must be protected at all times, as must the data from orders and invoices – in particular, the protection of personal data against unauthorized third-party access is essential for the DSGVO-compliant operation. It is therefore a good idea to clarify this point in detail with the data protection officer before designing the portal. The technical implementation must be based on a documented procedure for which data is transferred where and how long it is retained.
Planning for Failures
Every integration runs into problems at some point. The ERP may be unavailable due to maintenance, a certificate may expire unexpectedly, or an API may return data in a different structure due to a system update. The critical factor is whether these problems are obvious and can be resolved quickly. This is why it is important to plan for failures from the beginning of the project:
- Define how retries should work in case of short-term failures
- Make sure that faulty data records are either fixed or excluded from the transfer
- Agree on who should be notified in case of an error and how they should be informed (e-mail, ticketing system, …)
- Decide how a rerun of a failed data transfer should work
- Define what should happen if the ERP is unavailable when the TYPO3 website is being accessed
A good rule of thumb is to always provide default values in case of failures: if the ERP is unavailable, a page stating that stock information is currently unavailable is much better than displaying outdated information.
Testing and Launch
Testing should always be carried out with realistic data in order to identify errors early. Ten clean product master data records from the test ERP do not tell you much about the real master data with hundreds of irregular entries, missing descriptions, and strange characters in the product names. In the best case, a copy of the productive ERP is available for testing, with all personal and sensitive data anonymized. At the very least, it is necessary to agree on a representative sample of the data to be transferred.
The launch should also be staged: it is usually a good idea to start with one data set, for example the master data, and wait a few weeks before transferring the next data set, such as prices. This usually means that any problems can be localized more easily and the TYPO3 editor has enough time to get used to the changes. In the case of larger projects, it is also common for TYPO3 agencies to work with local experts in large cities. For companies that prefer personal contact, a local agency offering Softwareentwicklung in Hamburg could be a good option. However, it is essential to find a partner with the right specialist knowledge rather than one that is close by.
Conclusion: A Good Starting Point for a TYPO3 ERP Project
Before approaching TYPO3 agencies for cost estimates, it is a good idea to spend an afternoon compiling a rough overview of the fields to be transferred. It should be clarified which fields are to be transferred from where, which system is the source of truth for which field, how often the data should be transferred and what should happen in the event of a transfer error. If this information can be compiled, theTYPO3 agencies will be able to provide a meaningful offer based on it. If not, this is probably the place to start.
