IBM Sterling File Gateway Reviews

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.

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.

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.

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 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.

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.

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.

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.