There are some aspects of the front-end GUI, the actual queries that you use, that could be improved. They're all very minor to be honest. It's quite a nice modular system. It fits together quite well. The changes would be to the usability of the system at the front-end. It's not the underlying processing function of the system. It's how we maintain things and being able to see what's going on.

I find the solution quite confusing to use, especially when looking at the tree structure. I am having trouble with the settings and finding what I need. They are confusing. 

At this moment, everything is working fine. When we are talking to them, when we are trying to bring all this mapping in-house, right now, SEEBURGER is doing everything for us. 

However, when we are thinking of going onto the cloud, so they are not using any of AWS or Azure which are more stable. They have their own private cloud. That's the reason we did not go ahead with managing everything by ourselves or moving into the cloud. They said that they're going to be doing it within the next two years, having access to Azure and AWS. That would be something we would like to see.

The solution's documentation is not up to the mark and needs to be improved.

There are a lot of things that can be improved. One would be integration of the different products into one. Today they have their API management tool, they have the SEEBURGER legacy front end, and the entire BIS. In the BIS, if I want to have some API functionalities, that is a separate tool. The integration between the API tool and the BIS is not that straightforward. If they were to combine these tools and give us one suite, that would be helpful. Today I have a lot of partners onboard. I have something like 50,000 partners doing API transactions. If I want to introduce a new tool for API management, I have to do a lot of workarounds. But if it were integrated well within the existing suite, it could be straightforward for me. I would not have to reach out to all those partners and request that they change something. I could deal with that internally, within the suite itself. 

There are a few capabilities that have come out a little late. TIBCO introduced its container edition way back. It's been on the market for three or four. SEEBURGER is only in the initial phase of 6.7. If SEEBURGER could come up with and adopt changes really quickly, that would be better.

Their ability to future proof our business really depends on what sort of development they do and how fast they adopt changes. They are a little slow in releasing newer features. We are hopeful that SEEBURGER will change their internal processes to adopt changes a little quicker.

They have room to grow with the newest technologies.

We are a little locked in with understanding the errors that we receive. We are working with their support to prevent these issues when they come into the database. We use a SQL database and believe they can do better when it comes working with large databases. We have had few instances where the system is hanging, which are most likely from the database. We are working with their support to find out the problem and fix their system. We have tried to use their notification system to prevent these issues, but they need to improve their monitoring system.

All the topics we've identified have been placed on the SEEBURGER roadmap already. Our company is part of the SEEBURGER customer advisory board where some customers have been asked to give feedback. We give very open feedback to SEEBURGER, telling them what is not working properly. And all of our topics are already on the roadmap. They are close to their customers and try to fulfill their needs. Whatever needs to be improved will be there within one of the next service packs.

Among the things we have requested are improvements in the user interface and improvements that would be implemented by completely new modules or improvements in their Cloud Services. For example, because we are a global-facing company, we've recognized that we not only need some well-known e-invoicing mechanisms available over the SEEBURGER Cloud, but we need many. Even if there are smaller ones which are not well-known, the expectation is that SEEBURGER can provide them to us. SEEBURGER responded to that demand and provided services for countries where they've not had this before. The feedback on usability topics has been converted by SEEBURGER into improvements. We see them coming, step-wise, with each and every service pack.

The West Coast was thinking that SEEBURGER BIS would convert my maps, then they would own the process. The problem: There are times that we have to change dates or something in the map to facilitate what the business is looking to do for a partner. So, it turned out after much bellyaching on my part that this couldn't be done. So, I don't know if we can have a cloud solution and still own the maps. I think they are going towards that direction. We are looking to possibly have them host the server, but then the fees will go up.

The cost models have room for improvement. There are different licensing models between Europe and the USA, which is something that I don't understand. This is an aspect that needs to be improved.

Java is very old technology and they should move away from it, to anything that's better.

For the area that we've used them for so far, I don't really see any way that they can make it easier. I can't say enough about how they have delivered exactly what they said that they would, and for the cost and in the time that they said it would take. They're bang-on there.

It's rather difficult to understand, from the application, what's broken and why it doesn't work. We typically need to get support from them directly, and it's usually in a consulting role, to fix issues.

Also, the training they provide is not really adequate. They sell you things that you can use to design things in your own way. To get them to show you how those work is very difficult. To get them to explain how their application works sometimes is difficult (depending on the customization that was done) I would like to see them build training courses and I would have no issue paying for them. Everything I know about the application is self taught.

In addition, if we ask one consultant, we get one answer and if we ask a different consultant, we get a totally different answer. If we ask someone in Europe, even within the same company, we get a different answer again. They're not globally aligned in terms of what their application does and how it's actually installed. Depending on who you talk to, you get a different answer. You could say each consultant or software engineer has their own way of implementing BIS. They could do a better job if they collaborated more internally and talked to the customers and asked questions so that we could give them examples and tell them where they could do better.

Also, their release strategy, in terms of number of updates, is very demanding; it's very quick. SEEBURGER releases an update every month, if I'm not mistaken. It would be nice if they could do semi-annual releases that are not really needed. If something is broken, you can always ask them to provide a hotfix. We can't keep up with the number of patches they have (even though we may not need it). Every time they send a patch, we have to retest everything. They could improve the frequency of their patches and maybe provide a procedure to test everything so that we don't spend hours or days validating their latest update. We don't know what that patch is going to do. We have to test it and we need a team to test it. It's something that we do overnight. We have to check every adapter, every process row, all the modules in their solution.

We haven't really found that the solution's unified code base helps with problem resolution. Because it's a code-based system, we don't have much access to the logs or what's happening. So we have to log a ticket with SEEBURGER. We only get a message that something has failed. Sometimes the message is in German and it's very generic, very high-level. That could be improved, to see what's wrong, because often, it can be data-related but we have to open a ticket with SEEBURGER for them to tell us exactly what the issue is.

The error-tracking could be improved. That's a big thing. A customer will tell us they have an issue and we have to find out why it failed, because often it is a data-related issue. Maybe a field is too long or too short. I would like us to be able to be more self-sufficient. But I understand it's a cloud-based solution, so they have to own it. It's a shared system with other customers.

They made improvements to the email error alerts that go out, for the EDI technical. Those typically go straight out to the partners. Those messages are significantly clearer and easy to read. The same messages in the front end are not nearly as clear. It's supposed to be the same error, but the message that goes out for EDI is really easy for anybody to read and understand, but you have to be really solution-savvy to understand the message in the system itself.

That is the component that we definitely have the biggest issue with. Unless we want to go search for an email, trying to read the actual message in the platform is tough.

Also, some of the functionality for retriggering documents, where you have to step through a termination process and then retrigger it, versus just being able to restart or retrigger more easily, is a bit challenging, depending on the scenario.

We occasionally get ZIP files. Sometimes the ZIP file has one file inside of it, and sometimes the ZIP file might have 30 files inside of it. We have been working with SEEBURGER to enhance their PKUNZIP process to be able to unzip multiple files in a single workflow instead of just one file. This is still something that is in process. 

The BIS Front End needs a little bit of refreshing, especially when it comes to setting up new trading partners and trading partner agreements or transactions. It can be a bit clumsy to copy and rename and then go in and modify. That could be improved a little bit.

Also, on the server side, there are a lot of administration and configuration files that you need to go in and do maintenance on. You have to find them in a certain folder so it's very error-prone and it can be a little time consuming unless it's documented. They could pull some of those individual configuration files into the product itself where there's a better user interface for that.

In terms of adding features, they've recently talked about a few. One is a way to manage your web services or your APIs. That would be a big help because, right now, we have four web services and there's quite a lot of setup to each. They're in different areas within SEEBURGER Business Integration Suite (BIS). It's my understanding that they're going to be able to pull that together so you can view that entire setup in a more streamlined manner. That's something we're looking forward to.

There are a lot of service packs during the year. I know that part is the process for updating features, but sometimes it's difficult to update service packs every month.

There's always room for improvement. One of them is that the product is not integrated very well with different cloud providers. We did work with the vendor to build a solution for Amazon, but there is no solution for other cloud providers like Google or Azure. The vendor needs to create adapters so that if we have a requirement to transfer data from our data center to another cloud, outside of Amazon, we would be able to do that. 

Another issue is that support for the vendor's operating system is not available. There used to be support for the older operating system over SMB, but they have discontinued the support. They need to come up with a solution to support the new Windows operating system.

SEEBURGER Business Integration Suite does not have an end user or subscriber console which can show the traffic status. You have to be reliant on the consultants to do the customization. 

The integration is not so excellent. While I'm not saying there is a problem, there is no pattern. When we start a new project, we have to work with new people and processes every time. The technical side of their system is very good, but their change process is not repeatable. It needs to be rebuilt each time.

The ability to bind a mapping to an agreement seems a bit clunky. It would be nice to have a better way of navigating to a map name rather than using a drop down list.

The speed of development needs improvement. If you acquire any customization, it can be a slightly slow process. I would like to see more flexibility around customizations. The time frame right now depends on the sophistication and customization, but we have to go through a process of getting them to develop, implement, and test it. This might take a couple of weeks. If it was a simpler system to customize, the time could probably be cut by half or down by even 25 percent of what it would normally take.

Their traditional model is a vendor flow. We are looking to do a customer-based flow, which which require significant development from SEEBURGER. We are working with them to do this using their WebEDI. It is a brand new area for them, but it could be an option in the future.

API connectivity needs improvement as well as the GUI. The GUI hasn't changed that much in 10 years, but of course, that's already been updated. I would say I'm excited about the screenshots but that's about it.

• The interface and logging of messages could be more simplified. Everything is in Java and uses hash codes or UUID codes. This sometimes makes it very hard to know what has happened or what issue you might have.
• They could fix their protocol adapters so they really work with each OEM. Although it is sold with the OEM tag, you have to configure it to make it work as required.
• They tend to release a lot of service packs throughout the year, always fixing bugs that other customers report. It is as though they are building the system as time moves forward and providing enhancements.
• Monitoring of the application is very poor. You have to make custom scripts to monitor what is really important.

One thing that comes to mind is the service-oriented architecture. I have seen, in some of the other middleware tools, that you can create one service and then reuse it, without creating a copy. As I mentioned earlier, we create a copy of an existing map. In some of the other tools out there in the market, you can create one service and use that service without creating a copy. That kind of capability currently doesn't exist in this solution.

Also, these days, a lot of these companies are providing their solutions on the cloud. I think SEEBURGER has some presence there, but we're not really using it. For the future, they may have to provide more of a cloud-based solution.

We wanted to use API. We were told that in 6.52 we could use API management. Later on, we found that API management wasn't that completely integrated into the 6.52 solution, and if you wanted to have the whole API suite you might have to go to 6.7, the latest one.

We are waiting for that. There is talk that next year we might try to migrate to 6.7. Migration is not an issue on our side, but it's the customer migration which takes a lot of time. That involves a lot of concern and hard work because we have to have the customers onboarded as well and they need to do some testing. It's always really hard to get the customers to find time for that.

Error messages in the main area that could be better, but you can say that about any product.

The Front-End Monitoring tool part of Seeburger BIS 6, is a Java Web Start-based application. When a map (or transaction) fails, the errors go to a special section in monitoring, which is good. However, a lot of the times, when you are looking at the failure, it's one of those long Java.class failure descriptions. A lot of the times, in order to locate the error, you have to download the input data to your workstation, load the map that failed in your Seeburger BIS Developer Studio tool, run it there and then, debug it so as to locate the error.

One thing Seeburger BIS 6 is really good at, is enforcing standards (such as X12, EDIFACT, etc.) but, this can also bite you. When partners don't follow the standards, then the actual standard that is violated, doesn't necessarily jump at you in the Monitoring tool. You have to debug the data received and the map. This is from my experience with many tools, especially those built on Java. This kind of thing is not specific to Seeburger BIS, in my experience.

There might be some improvements they could make to the portal, but they're not anything that stops me from working.

Nothing comes to mind at the moment. I would describe it as a very robust solution which is oriented towards ease-of-use. It has small bugs, like any other software, but constant patches and feature add-ons are taking care of that.

I would've liked, from day one, to learn how to do my own mapping. It would have saved a lot of time and effort if that had been brought forward earlier. It's there, I just didn't know about it.

Also, some tidier, easier-to-use interfaces would help.

A true debugger that allows you to step through the process would be a good improvement. Right now, we are limited to reading the log file generated by the test screen in Mapping Designer.

Difficult in handling large amounts of data, like when the file has more than 100MB in size. Therefore, our organization had to purchase another server to deal with this.

I would like there to be a feature that could handle the limited server.

The connectivity of the Data Distribution Center (DDC) and the repository need improvement.

The documentation can be improved.