IBM Sterling File Gateway Reviews

I have been dealing with IBM Sterling File Gateway for some time, and we have sold to about six customers across India with the help of IBM. One large bank which we have sold this solution to is SBM, that is State Bank of Mauritius, which was earlier Mauritius Bank, but an Indian entity. The whole idea is to replace IBM from there because they would prefer to reduce the cost of operation. So they are looking out for an economical solution. I was just doing website management and happened to get your name. I think you also had sent some email yesterday asking if I was looking for something. I do not know how you got my email address, but it may be a mass mailing solution which you would have done. From that mail, I went through your website and thought it was interesting to get exploration and look at how the technology works within the company. That's where I ended up registering and taking the comparison brochures.

In terms of automation capabilities, most of the customers have automation. The software has automation that at a fixed point in time triggers the copying of file A to B. Automation is working fair for all my customers and was never a problem.

Regarding sophisticated automation of various utilities which include video and audio, I have not witnessed those because there are few components where we would prefer to use your software for video mobility from currently NAS device to cloud or something similar. We have not explored automation on audio, video and different horizons. For example, folder A should go to sandbox A, folder B should go to sandbox B, folder C should go to local NAS - those levels of automation we have not tried. I cannot answer fully because automation is something which we have never recommended to customers, nor have customers asked what they are looking for from an automation point of view.

The disadvantages I see in IBM Sterling File Gateway include price and reporting. Reporting is not very easy. If 10 people are putting file transfer using this protocol, determining who did what file transfer, how long it took, what encryption was done, and whether it was accessed by somebody or whether it was fully done without any retrial is difficult. Reporting is a big problem in IBM tool, according to our customers' complaints.

When there is an audit requiring proof that a file has gone in a secure way, most customers have not been able to prove it. Additionally, when there is a large file transfer which has to be done in multiple pieces because of bandwidth restriction, they have not been able to do splitting. The splitting was not possible during file transfer. Many customers have asked if they can split the file and then send it, or pick and choose and send it from a large file. It was also found that it was hogging the bandwidth whenever it was doing file transfer. Ultimately, we ended up selling HP also.

The tracking and monitoring features of IBM Sterling File Gateway present some challenges, particularly with tracking, monitoring and compliance issues which RBI is asking for. While it was possible to address these issues, it required an expert to figure it out. When expertise business activity is required, it costs money to customers who are not willing to pay.

Regarding future features to make it more competitive, automation email could be one feature I recommend where once the file transfer is done, an email or log should be created for the admin person confirming successful completion. Second is 24/7 support in case of any issues. IBM has never been able to give round-the-clock support whereas customers can ship files even at midnight. Our support is also based on support from IBM. The third improvement area could be automation release notes. IBM has never given us or customers notifications when a new release or patch has come. Whenever a patch is released, an email should go to the buyer or user and to the reseller so they can sync up whether to upgrade the patch or not.

I have been working in this field for 26 years.

We do not use any specific metrics to measure the performance and efficiency of the file transfers, as we have never done that exercise.

Regarding the technical support of IBM Sterling File Gateway, I would rate their job about nine. Technically, I don't see any challenge. The only issue is it takes a little while to get support.

Positive

I find the deployment of IBM Sterling File Gateway is not very difficult because we have done it at six locations, so we don't face many problems. The only challenge is that many times the firewall rules have to be changed for opening the ports, which normally takes time because of the security policy which many customers have. They need approval and they need testing and UAT. The time-consuming part is only port opening and port management, both at server level as well as firewall level. Otherwise, it's suitable for our team to deploy.

We have never sold any other product except IBM Sterling File Gateway if it doesn't fit the budget of the client.

The reviewer gave IBM Sterling File Gateway a rating of 7 out of 10.

I work for a manufacturing company. They use it for the B2B landscape. They use IBM Sterling Integrator for both the EDI transactions and managed file transfers. We have Sterling File Gateway as well as the Integrator for translation. 

We have two different environments to handle, and we have close to 12,000 suppliers and carriers. They do EDI transactions through us using Sterling Integrator. We facilitate the EDI transition to the respective SAP equivalent data translations, whether it’s an IDOC or a flat-file, based on the requirements. We also onboard the Sterling partners on the system, whoever wants to do EDI.

When it comes to automating file transfer in a business process here, it has been automated-- a user drops the file into the mailbox, and it just auto-triggers as per the schedules to execute the series of steps that we would have written in that workflow. That is how automation is conducted.

We need not worry about the file delivery because it takes care of itself. If there are any errors, we have an error handling mechanism defined within the workflow itself, which details out on which step the error actually occurred, what the error was, and things like that. 

There are some common errors which we can find out through the Business Flow logs. It is quite self-defined on its own with respect to Sterling.

I really like its offer of a system and business process that handles inbound and outbound transactions. That feature I like which is built. We can do customization on top of it. 

Beyond that, the way the mailboxes are defined and the way we can connect to them and trace down the EDI file is a feature that I like. 

In comparison to any other tools, the UI is very user-friendly to understand and the way it has been categorized.

I’ve been part of this client for the last seven-plus years. It’s been close to 70 to 80 continuous improvements we have delivered. The priority ones which we always shortlist are the recurring incidents or recurring issues, which came in the initial phase of the year when we took this entire landscape under our maintenance. 

One such incident I can recollect is with respect to performance tuning. We committed to our users 99.99% and above as the availability metrics for Sterling Integrator. This has acted as a high-availability system, but we treat it as mission-critical. When it comes to the commitment we give to users, we have to ensure the system is kept most stable.

So, the majority of the problem was in the communication channels. Whenever we enabled additional logging for the communication channel, the system used to have hiccups.

So we worked with the vendor, stating that the visibility channel framework needs to be changed because the moment we enable more logging, it literally brings the system down, or the system doesn’t work as it should. They took our input and delivered a better framework in their next releases, which helped us after upgrading to have that stability intact. As the system grows, we ensure to have performance tuning triggered and optimize the business process wherever required. 

For example, by default, Sterling Integrator business process will have full logging enabled. We took care of those things. Not all business processes or workflows require full logging enabled. Only a few critical ones require every step logs. 

For the rest, we categorized and reduced the logging for those workflows. That actually helped us to increase the IO overall from ten milliseconds to six milliseconds. That was a good achievement.

Apart from that, in terms of queues, how we maintain the queues, how we defined all file queues across the critical business process is one thing we felt was done better. The threads we assign for the priority queues and the business processes were configured to those priority queues, whatever is critical, so that it gets high priority to allow the threads to process.  So that queue thread Sterling was taken under the performance tuning.

Apart from that, I think some of the best practices which IBM recommends is what we usually run through every year. We just have the health check done through IBM, and we just ensure that all the best practice recommendations are added in the system.

For the last seven-plus years, I have been working on Sterling Integrator. My overall experience in the integrations field is close to fifteen years now.

Overall experience in the integrations field is close to fifteen years now.

Scalability depends on the underlying business needs. So if the system requires adding a number of cores, we can scale it as per the requirement. 

For example, as of today, we support close to three to four million transactions per month. For that, we have a set of underlying infrastructure built around, which might be 12 cores in each node, good enough to throw out some 70 threads for these transactions to be handled. And we still have some room to occupy for more volume increase. The moment we feel that there is more volume coming in on a monthly basis, it turns five million.

That’s when we have to think about scalability. As of now, there is vertical scaling happening in the current environment, but we can go for horizontal scaling.

I would rate scalability an eight out of ten. Whenever there is a need to add additional resources and scale it, we touch every section. For example, we touch the database, the underlying Linux, and any file system. We also ensure network feasibility is available. So, I would rate it eight out of ten.

There are no major challenges, but there are a few hiccups in terms of connectivity. Whenever we do performance tuning, things usually go right. The only challenges we face are with CPU utilization or memory allocations. We might have configured too little or too much based on the current system availability. When the CPUs or file monitors are overloaded, it crashes. So, those are the factors that pose problems during scalability.

We have ongoing vendor management with IBM for any system-critical issues or questions about features. We ask if we can enable certain features and if we need to take care of anything before enabling them. We also contact them for system-down scenarios. We have an IBM portal where we open a PMR, and they assist us. Most of our questions are about upgrades, vulnerabilities, and system-down scenarios. As part of the n-1 version maintenance, we follow a trend of upgrading to the latest version to use all the features IBM offers.

Whenever we do any upgrade, we tend to encounter some issues. These can be known issues or new ones we discover for IBM.

We have a few hiccups here and there in terms of the people who support IBM. It probably depends on the person who is actually taking care of the PMR.

We have very good support members who are very knowledgeable, but we also have a downside where a few people are probably new to the team and do not understand the criticality.

But ultimately, whenever the ticket goes to the engineering team, we always have the answer.

Positive

I’ve been part of multiple integrators, right from SAP Process Integration to SAP PO Process Orchestration. I began my career on SAP and then moved to IBM product, which is Sterling Integrator. So, I have knowledge of multiple integration tools.

The product is not cheap. With respect to pricing, IBM is in the top two or top three after SAP.

It is worth it. But it definitely depends on the environment and the requirements. So it can change. IBM can be suited for multiple scenarios or environments, but it may not be suitable for a few as well.

I would definitely recommend it to other people. I would definitely recommend it in terms of the user interface that IBM has today and the support model they have because I have not come across such a good support model in different integration spaces. 

Overall, I would rate it an eight out of ten. 

We primarily use Sterling File Gateway for partner-specific file transfers, both inbound and outbound connections. We use it for any generic file transfers and monitoring purposes related to the AS2 protocol. 

Additionally, we have Sterling B2B Integrator for complex business process flows. My core competencies lie in Sterling File Gateway, Sterling B2B Integrator, and various file transfer protocols like FTP, HTTP, and AS2, as well as APIs.

I have also generated custom tasks based on customer requirements, such as PDF generation and PGP encryption/decryption. 

Also, I've worked with the Control Center to generate error reports and create system issue alerts. 

Mostly, I have worked to avoid manual work and I've focused on automating processes to reduce manual work previously done by the support team.

Mostly, I get tasked to work on development activities about 90% of the time. I only get support activities like to monitor and automate manual work a small percentage of the time.

The automation of file transfer protocols impacted our workflow.

We create a stored procedure in the database and use it in our business processes based on time periods. For example, if a customer needs to pull files from their system between 6 PM and 6:30 PM IST, our business process will run every half hour and place the customer record. 

Then, we'll select the appropriate protocol for the customer (SFTP, FTP, or HTTP) and perform checks like file renaming, PGP encryption, archiving, and auditing. If required, we flag these in the database and pull records from the source system accordingly.

I work as a lead in the current project, and I provide training to four resources. We need to provide proper training, and it takes one or two months for them to gain the knowledge. It's not that difficult. 

If we are passionate about learning these things, we can learn easily. Based on my experience, if you want to put in complete effort, you can learn and implement any logic.

Sterling B2B Integrator has multiple options. If something is not possible within it, we can implement Java code using services or shell scripting to fulfill our tasks. We can also migrate components.

I like the setup while creating templates in Sterling File Gateway. Most of the logic depends on the template, how we create and manage it. 

Also, code optimization with minimal code and reusing functionalities are good features. 

I've worked on generic flows for all the protocols, which is the best part of my work. It took me one month to master.

For error handling, we generate an error report based on complete with error status and complete with heartbeat status. We then filter the inbound and outbound flows and assign them to the appropriate teams. Most errors, around 70-80%, are repeated errors, while 20% are new errors. 

When I develop and hand it over to the support team, I monitor for one month. During that period, if any issues arise, I'll check with the customer or try to resolve them and provide guidance to the support team.

There is room for improvement. For example, when transferring files, there are some features like custom protocols. Currently, we only have four protocols enabled: FTP, SFTP, Connect Direct, and MQ. 

I haven't worked on it, but I have some theoretical knowledge on the use of custom protocols. You can include custom protocols in Sterling File Gateway.

Basically, in SAP, we need to create the entire business process in the dashboard and build the logic. But in Sterling File Gateway, we don't need to build any logic. We just need to use the required components. We can also add new protocols, which I'm currently working on.

I have been using it for six years now. 

We have issues with the stability of this solution, like server-down issues. And whenever we upgrade our servers from one version to a higher version, we face a lot of issues. We need to monitor our server for any increase in hardware BP count or system downtime. 

For example, if a server goes down, we'll get thousands of files in an interrupted, managed, halted, or failed state. We need to check all those things and reprocess those files.

For Sterling File Gateway, I can rate the stability as an eight out of ten.

The scalability of the product is good. I would rate it an eight out of ten.

We have around 20-30 members, and mostly five to six members are using it. The remaining people work on other tools like Control Center.

I haven't had a chance to work with them directly, but as per my knowledge, whenever an issue isn't resolved from our end, we need to raise an IBM support ticket. We reach out to them, they provide solutions, and we follow up based on that.

Deployment activities are done by our lead or Sterling manager. There's no difficulty, but we need to be very careful. Even when deploying a small component in production, we need to check multiple times because a small issue can cause big problems. 

That's why we need to be cautious when reprocessing or deploying anything. For example, if we migrate components, we need to create an Excel sheet or some kind of checklist to ensure they migrate successfully. Multiple checks are necessary.

It is worth it. I mostly work on retail flows like orders, invoices, and shipment notices.

A few components in this IBM tool, like WTX, are costly compared to the Map Editor, as per my knowledge. I don't know about the rest.

I would recommend it. Sterling File Gateway is a good tool compared to others. It has some advantages like monitoring capabilities, high transfer visibility, scalability, and easy reprocessing of failed or used files. It also has good error-handling methods.

Overall, I would rate it an eight out of ten. 

We use IBM Sterling File Gateway for partner onboarding, both external and internal, who need to transfer files. It allows end-to-end onboarding of partners. Based on partner needs, we can handle different file patterns, renaming, PGP encryption, and general file encryption.

What I like best is that the tool is very secure and reliable. We can send huge files, even up to hundreds of GB. The automation depends on the source - it can be through automated processes, manual transfers, shell scripting, or file scripting. Partners can schedule batches according to their needs.

While anyone can use it, they need some training. Usually, two to three weeks of knowledge transfer is enough for someone to use this file transfer tool easily. We have logs available in the file transfer process for error handling. From these logs, we can see the error, how to fix it, and how to contact the end user who needs these files. All of this is covered in the training process.

Based on my experience, there's some room for improvement. We're currently using version 6.1.1, which has a limitation where files are purged after seven days. We have to restart the purge count manually through our standard procedure. This issue should be resolved in the latest version.

I have been using the product since last year. 

We rarely encounter issues, but sometimes file transfer is slow, especially when handling large or numerous files. We rectify these issues within our SLA period and inform users. We also perform maintenance activities twice a year to ensure the proper functioning of all servers. I rate the solution an eight to nine out of ten. 

The solution is scalable. 

While it's more expensive than other tools, we get proper support from IBM. They're always on standby, providing 24/7 support when our team cannot resolve an issue. Our organization has standard-oriented procedures and proper documentation, which benefits any organization using this tool. It is very supportive. We have a process to raise cases with IBM when issues arise. We resolve most P1 or P2 issues (about 95% of cases) within our team. Only in 2-5% of cases do we need IBM's support, and there's a mechanism in place for that.

The initial setup and deployment are relatively easy. It's not very complex, and you can set it up through an easy process.

I believe the tool is worth the money. While there are many user-friendly tools on the market, they often have issues when you start using them extensively. From my experience with other tools, they weren't as user-friendly, and the support wasn't as good as what we get with IBM Sterling File Gateway.

I would recommend IBM Sterling File Gateway to organizations. For newcomers, my advice would be to get proper knowledge transfer . You can start working from the first day with side-by-side KT. It's helpful to practice using the tool in a UAT or development environment to get familiar with it.

I rate it an eight out of ten. 

I've been working with EDI. The main proposal of acquiring IBM Sterling File Gateway was to replace two other platforms that we had here before. We had Connect:Direct, an EDI platform, and Sterling Connect:Enterprise, a mailbox system made for use with external partners. 

With Sterling File Gateway, we acquired a platform to replace these two different platforms because Ceramic Pro had plenty of different protocols, like Connect:Direct, SFTP, ESTP, etc. It also has a built-in mailbox platform, so it consolidated the functionalities we used different platforms for.

Sterling File Gateway enabled us to consolidate multiple protocols and mailboxes into one platform, thus replacing two separate systems we had before. This consolidation brought simplicity and efficiency to our file transfer operations.

The best part about Sterling File Gateway is that it speaks many different protocols. I can receive and file using SFTP and retransmit it using another protocol like Connect:Direct. 

It offers flexibility in transforming files, changing names, extensions, and utilizing EDI functions like extracting information from a database and placing it into a file. It is a very flexible platform, and this flexibility is the best part of it.

The automation part is somewhat limited. Compared to platforms like Confluent, Sterling File Gateway is a bit restricted. Confluent offers many options for creating complex schedules and research. Although I can create various keystone schedules, it requires a lot of effort. Furthermore, the licensing method IBM uses, called PVU, is not favorable. 

It charges more based on the physical machine's specifications, even if you're running the application in a virtual environment. IBM should use a different method for licensing. Besides these, IBM Sterling File Gateway is worth the cost.

I've been working with IBM Sterling File Gateway for about four years now.

Sterling File Gateway is a very robust and reliable platform. We had very few problems with it, and IBM usually provides us with plenty of patches to maintain its reliability.

Scalability is quite simple with Sterling File Gateway. The platform offers many configurations for high availability, allowing us to scale up or down easily. We use containerized applications via Docker for this purpose, so we can scale different components of the platform without affecting our licensing.

IBM's support team is great. We pay for 24/7 support, and although outside regular hours, we might be assisted by international teams, so we are well-supported.

Positive

We replaced Connect:Direct, an EDI platform, and Sterling Connect:Enterprise, a mailbox system, with Sterling File Gateway to consolidate our protocols and mailbox functionalities into one platform.

The initial setup is a little bit difficult. It involves dealing with a large XML file where every line represents a different configuration. You have to manually set up the file and know exactly what each line corresponds to before installation.

The licensing method IBM uses, called PVU, charges more based on the physical machine's specifications, even if you're running the application in a virtual environment. 

IBM could charge us less, especially using a different method. While Sterling File Gateway is expensive, it is worth the cost.

I would recommend IBM Sterling File Gateway as it is a very nice platform. Despite some limitations, it provides extensive flexibility and functionalities.

The solution was used for file transfer without any translation or transformation. We were pushing whatever files that were coming into the source. In the earlier project, we used the managed file transfer. It was a part of the process. The major part was translation using IBM map editor, the trained partner set up map creation. We had the MFT (Managed file transfer) as a minor part.

We did not encourage much customization. We had a standard role where the source would place a file in the mailbox, and we recommended using the destination mailbox prefix. Our business process was written in a way that when it finds the destination mailbox name fixed, it picks it up and sends it to the exact destination. We had IBM Sterling File Gateway in place for that.

One feature that we appreciate or use for multiple customers is the routing channel. We can provide particular instructions to the file gateway on routing the files. It was limited in the earlier project, and we had a defined custom web. However, not all projects would be on the same web. We can have different channels created or designed for each partner depending on their requests.

The tool would be new to a fresher who won't understand anything without experience. The solution should provide content or videos explaining to freshers how to configure it and what every field means.

When we have SFTP communication, where we need to link a communication channel with a protocol like SFTP, we first have to configure the SFTP connections in IBM's dashboard. Then, that would be listed in IBM Sterling File Gateway. We had to remember the exact name we had provided in the dashboard. Otherwise, we had to scroll and check everything, which was pretty difficult.

If a project had over 200 SFTP connections, we had to go through all the protocols and see where that exact SFTP name was located. This probably could be one area of improvement.

I have been using IBM Sterling File Gateway for five and a half years.

IBM Sterling File Gateway is a stable product, and we didn't encounter many bugs. It was also easy to track the issues. In case of a failure, we can check the logs and see where it exactly failed. We can also track at which protocol or step it was able to connect to the server and whether it failed during the write.

In my previous organization, around 20 projects used IBM Sterling File Gateway.

Deploying the solution in different environments, such as development, testing, and production, was pretty easy.

The solution's pricing is reasonable. IBM Sterling File Gateway is worth the money. The licensing cost is the only cost involved. Whenever customers ask for access, we do not provide them with read and write access. They would not have admin access. They would just have read access to see the file flow, which does not come under license.

I would recommend the solution to other users because it is a good tool for file transfer, where even customers can access or view the file flow.

If there is a communication we need to create between the source and destination, it's pretty easy to have it synced and created with the routing channel. The tool creates trouble when pointing out the SFTP connections. It is difficult for a beginner to understand the solution.

Overall, I rate the solution an eight out of ten.

We have a claims department where 70% of employees handle claims, creating insurance documents based on requests from our members. Once the claims are generated, they are placed in specific folders as directed by the business. We use a job scheduler to pick up these files from the specified directory. The scheduler is configured to pick up files every four hours and deliver them to the destination. In IBM Sterling File Gateway (SFG), we configure the directory paths and set up partner profiles to ensure the files are transferred correctly. We often use static routing channels involving one-to-one connections between source and destination. Sometimes, we use dynamic channels when there’s one source and multiple destinations. We monitor file transfers 24/7, prioritizing issues as P1, P2, or P3, depending on their urgency. For P1 issues, we must respond within 15 minutes and resolve them within 4 to 8 hours. Common problems include directory path changes not communicated to our SFG team, SSH hosts vital issues, and server downtime during file transfer attempts.

We regularly monitor, especially during maintenance periods, usually during non-business hours. After maintenance, we generate reports in Excel to analyze failed files, identify producer and consumer IDs, and replay failed files. If replaying files doesn’t resolve the issue, we conduct a root cause analysis by checking the instance ID in the SFG and reviewing the services that encountered errors.

When the file flow is high, the chances of failure increase, so we closely monitor the situation. If thousands of files fail due to high flow, we send a high-priority reminder email to the clients and temporarily disable the scheduler to avoid further issues. Once the flow normalizes, we re-enable the scheduler, and the files are processed accordingly.

In IBM Sterling File Gateway, automation primarily involves schedulers, which significantly transfer daily generated claim files to the end user. We ensure that the directory and files are up to date, particularly those placed in specific directories by the source. Processing can stop if someonechanges the directory without updating it in the SFG partner profile.

On the destination side, after setting up a partner file, we provide the end user with an MFT link, user ID, password, and a guide on uploading, downloading, and viewing files. Initially, we set up a primary password for them, and they can later change it to a preferred one for viewing their files.

This process ensures smooth file handling, but miscommunication regarding directory changes can lead to issues.

The number of failed files number increases with high workflow so that needs improvement. 

I would rate IBM Sterling File Gateway as an eight on a stability scale from one to ten. Initially, we faced issues due to limited on-premises database capacity, especially when multiple customers uploaded thousands of files simultaneously. To address this, we migrated to a cloud platform, significantly reducing file failures and stabilizing the system. Now, we primarily focus on monitoring queues and managing scheduling, with fewer issues overall.

Regarding scalability, I would give it a nine. The highly scalable product supports variousprotocol communications and integrates well with the Sterling Integrator (SI) for admin activities. We can handle more users, use dynamic channels, and securely encrypt documents, ensuring only authorized end users can access the files.

Regarding technical support, I've never needed to contact IBM's support team directly, as our internal team usually troubleshoots any issues.

Compared to other tools like Dell Boomi and Axway, I believe IBM Sterling File Gateway is the best option.

I do know that it's generally considered expensive, but it's also widely used across corporate organizations due to its robust protocol communication, secure file transfer capabilities, and integration features. Although there are other tools on the market, IBM Sterling File Gateway stands out for its unique options and cloud compatibility, which offers future benefits, particularly in avoiding data storage issues.

I would recommend IBM Sterling File Gateway to others, especially if they're starting a project that requires secure file transfers and integration. This tool plays a vital role in any organization. My advice to newcomers is to consider how long the project will last so that you can optimize costs with IBM. The package can be customized based on your project needs, whether yearly or bi-yearly, ensuring you don’t overspend.

Additionally, IBM Sterling File Gateway has cloud compatibility, a great feature if you need to migrate from on-premise to cloud storage. All administrative activities, like changing passwords or managing user profiles, can be done quickly within the system. I would rate IBM Sterling File Gateway as a nine out of ten.

I use Sterling File Gateway to check the routing status of files - if they're failed or successfully translated to the consumer. Mainly, we create trading partners using Sterling File Gateway, with different protocols and create routing channels to send files between partners. 

We need routes between these partners. So, using Sterling File Gateway, we create these routes using templates. We can also check the status of the file there. If a file fails, we can see where it failed and in which process it's getting stuck.

During my engineering studies, I had never heard of Sterling File Gateway. However, after joining my first company, I received training on Java and other technologies and was then assigned to work with Sterling File Gateway. The company provided a 15-day training session to help me understand the product. 

Once I started learning Sterling on my own, I began creating trading partners and establishing flows between them. It didn't take long to understand the system. Even someone without a technical background could easily learn Sterling File Gateway. It's a very helpful and user-friendly tool.

I like its ability to communicate in B2B scenarios. We can act as either the producer, sending files to the consumer, or as middleware between trading partners, collecting files from one and sending them to another. Sterling File Gateway enables us to create this communication and act as a middleware.

Sometimes, for example, when using the SFTP protocol, we need Sterling B2B Integrator to create the remote protocol. As you know, if you use SFTP, SDC is the binding agent, so we also need to check with the AS2 File Gateway and AS2 Integrator to create the SSH profile. If we could create the SSH profile directly in Sterling File Gateway, that would be an improvement.

Also, when creating a trading partner, we have the feature to create a producer as an initiating producer. But we don't have an option for a Sterling producer in the File Gateway. We need REST APIs or other tools to create that listening producer. If we could get that feature in Sterling File Gateway, that would be more helpful.

I have been using it for three and a half years. For the first one and a half years, I worked on the cloud-based version. Now, I use it on on-premises.

I use the version 6.1.2.

Most of the time, I don't see any bugs in Sterling File Gateway. In Sterling File Gateway, you have the B2B console option. In B2B, we have different instances where we can see most of the things. 

Suppose we get notifications on the homepage; sometimes, if you don't clear those notifications, it can cause performance issues in the application. So, sometimes, I face issues accessing the dashboard.

As a developer, it's really scalable to use. In my company, I previously worked on some DGMSs. In that, I didn't see many large projects. I saw two or three projects related to IBM Sterling Integrator. 

Most clients now use EDI. In EDI, there are different tools, like Cyclone, GlobalScape, and Dell Boomi. Some use Sterling File Gateway or Sterling Integrator, while others use different tools for B2B communication using these kinds of protocols. So, out of ten people, only two to three use Sterling File Gateway or Sterling Integrator.

Most of the time, we face some issues. Sometimes there are errors that we don't understand, file-related, backend things. As a developer, I work on the frontend part. But sometimes, I see in the backend that there are issues if someone installs any JDK or SDK. Suppose there's a bug or something in that SDK; we need steps for proper installation. In those cases, we raise an IBM case and contact them for help.

It's not difficult. Even a non-technical person can learn Sterling File Gateway within two or three weeks. It won't take more than that. The GUI is really handy.

I've heard also that maintaining Sterling, whether it's cloud-based or on-premises, requires more resources compared to other tools.

I would give it a nine out of ten. I've been working with it for the past year, primarily on the development side. On-site teams often give me four to five days to create flows, but it's a very easy tool to use. It usually only takes me four to five hours to complete a task. Once you understand how to use Sterling File Gateway, it becomes even quicker to work on other tasks.

I use the solution in my company since we have lots of different use cases attached to the tool. Mainly, we have incoming flow in SFTP or SCP protocols. Some of the files are pushed to local file systems or other internal servers. For outgoing flow, we have BMC Software to control and receive orders and push files to the server using different protocols. We also have a few specific business processes to connect HTTPS servers to get or push files.

The solution's most valuable feature revolves around the tool's engines, which can do many different things.

The weakness is that the engines associated with the tool require too much expertise to master how they work.

Finding people who know the product from the market or choosing IT personnel to work with can be challenging.

Improvements can be made to the tool's user interface and user experience. It would be good for the tool to develop a command-line interface to replace all the scripts present in the product and execute all the different scripts.

Currently, what we are looking at in the tool is already in development. It should support different storage solutions on the cloud, be it on AWS Azure, Google, or even if it is something different, like S3. The product is currently integrating with the full support of the protocols. There should be support for different storage solutions on the cloud. I want the tool to support Google Drive.

I feel the tool's setup process could be made better, but it can be difficult because the tool's vendor has been proposing a lot of different implementation methods. You can use it on the cloud or install it on the cloud, Windows, or Linux, and the tool needs to manage it on all the different operational systems. On the on-premises part, it is different from how it is on the cloud. For me, being able to install the tool can be complicated if I consider how I want to configure it. I want the tool to offer a CLI or a command line interface to help the users figure out how to work with the tool.

The tool's scalability can be made better. Currently, we are using a cluster, so you can always add more nodes. You can upgrade each node and its capacity for processing. In the cluster, when you add a node, you don't do just one node, so the cluster needs some processing abilities to manage all the nodes. It is a very scalable tool, and it has good capability. If you go for the cloud installation instead of an on-premises one, you are able to develop the scalability for any project on the cloud because it has the infrastructure to process as many nodes as you need.

I think what could be improved for the support is understanding that any answer must be used by the user in practice. Sometimes, when you have an answer, it is not acceptable because sometimes it is not defined. Sometimes, when the product is improved or supports some new feature, it acts too limited to be useful. My issue is that depending on the module you want support for, you can have good support, but the support is more like five or four out of ten because the support changes and doesn't understand how the product is used by the user or how it should work. I recently raised a ticket with support. We had an issue with the tool, and the support had one of my previous tickets but told me to do something, and I found that the response was not good. The support wanted us to change our environment parameters, which would have an impact on the other software tools. The support did not understand, and it was hard for us to explain that we could not break all those systems just to correct the issue on a single software. Lots of exchanges had to happen between our company and the support team just to explain a response to an issue in practice and in theory. The support team's solution could be great, but in practice, it was not so good.

I have been using IBM Sterling File Gateway for ten years. I am just a user of the solution.

It is a stable solution. Stability-wise, I rate the solution an eight out of ten. The issue is with the resource, so when you install the product, you will face some limits on what can be used. Sometimes, if you have four to five systems or if you have four CPUs, it will meet its limits, but it is the resource that IBM needs where there are limits.

It is a very good and scalable solution. Scalability-wise, I rate the solution an eight out of ten.

The solution's technical support is sometimes slow to understand the use cases, and the answers are not practical. The responses from the technical team cannot be used. I rate the technical support a four out of ten.

Neutral

If ten means the setup process is difficult, I rate the product's initial setup phase as a two out of ten.

The product's initial setup phase is hard because there are a lot of things you need to finetune in the product. We are using it in a highly resilient and highly available configuration. We are using the tool across different areas. If ten means very easy setup, I rate the setup phase as two or three out of ten. It is too difficult to implement the software. I know how to use the tool. I know how to use the tool, but a lot of people don't have it. I am still in the process of learning more about IBM Sterling File Gateway, and I plan to use Secure Proxy. We are using the external authentication server. All the software needs to work together, and sometimes, it is difficult to know which one you need to begin with and how it works between them. I think the tool is difficult to begin working with during the initial stages. You can have some easier solutions, but you will lose out on the high availability or the high resilience functionality offered by IBM Sterling File Gateway.

The solution is deployed on an on-premises model as a cluster in our data center.

For deployment, I updated the application systems. I had a project for eighty days. We had to keep all the previous data on the configurations, and I didn't have all the process-related documentation. I had a lot of work to do. During installation of the product, a one-day operation is needed. You install the tool in several different environments and servers, and you need to configure everything together to be able to check everything, and that is where you lose out on a lot of time. The time needed to deploy the tool depends more on your knowledge of the tool. The configuration takes much more time than the setup itself.

The time required to learn to use the tool depends on the level you want to use it. The tool's use can be learned in one or two weeks, but generally, you need a lot of generic knowledge. To be able to completely work on the tool, you would need several months.

The biggest advantage of the tool is that it acts as a centralized solution for all the different protocols. From our company, we are using, but not directly installing, the IBM Sterling File Gateway. However, we are using the basic protocols with it.

One needs to have a lot of knowledge to use the tool. You need to read a lot of documentation, participate in the community, and do several other things.

I rate the tool a nine out of ten.

I utilized Sterling primarily for SFTP and Connect Direct. I have a complicated system involving ZOS mainframe, data power, and various complex rules as I was trying to replace everything with Sterling.

Connect Direct was valuable for me as I am using it live in my system.

The product itself wasn't very easy to comprehend. I required a lot of customization that didn’t meet my needs. I resolved more issues than IBM did. Sterling needs better testing for larger customers and requires improvement as it is pretty outdated.

I spent over two and a half years with the solution before the project was pulled.

I faced issues during stress testing. The product wasn’t live, and I had many performance issues.

Scalability is fine. Scaling requires considering licensing costs if you expand.

Their support was a five out of ten. They need to have better technical staff and more comprehensive testing for larger customers.

Neutral

I had a combination of different MFT solutions, and the idea was to unify them. Details on previous solutions are currently under evaluation, so there is no clear predecessor.

The initial installation was straightforward. That said, the architecture was complex due to my networking. 

Initially, the setup was quick, but creating the intended setup took longer in development, involving multiple people due to my complex environment.

Currently, there is an evaluation of new solutions, however, specifics are not available.

My management is considering other options. I would rate Sterling File Gateway a five out of ten.