Skip to Main Content
IBM Sterling


This portal is to open public enhancement requests for IBM Sterling products and services. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Needs more information
Categories Usability
Created by Guest
Created on Jan 31, 2024

Global Mailbox aged documents or orphan file deletion

On a B2B Integrator software, where HighAvailability is not needed, the payload storage is on shared drive with a simple directory path /opt/b2bsi/documents/2024/01/..... the path has a linear map towards the payload storage. Even if payload gets redundant, we could see easily use a find command and find it.


While using globalMailbox orphaned payload removal/deletion is tedious as the path points like below


/opt/b2bsi/documents/global_mbx_var_00

/opt/b2bsi/documents/global_mbx_var_01

/opt/b2bsi/documents/global_mbx_var_02

/opt/b2bsi/documents/global_mbx_var_03

/opt/b2bsi/documents/global_mbx_var_04


We do have BP that cleans up payload older than x number of days, but it really does not go deeper than x [say for example 20 days, 30 days, 40 days old payload.]

It would be helpful if IBM builds a BP that could easily remove old payload from above paths, than being dependent on OS binaries to search through Terabytes of data in above paths, eventually causing timeout on server.


What is your industry? Healthcare
How will this idea be used?

It would be helpful if IBM builds a BP that could easily remove old payload from above paths, than being dependent on OS binaries to search through Terabytes of data in above paths, eventually causing timeout on server.

  • Admin
    Mark Allen
    Reply
    |
    Apr 17, 2024

    Thanks Peter for the information. A couple of follow up questions from our development team:

    1. While GM stores messages and payloads in Cassandra, are you querying Cassandra to get the list of records? What criteria are you using to identify these records? Are you using CQL?

    2. The MailboxDeleteAllService is fairly destructive, would a GM native version of this be useful? The MailboxDeleteService does support GM, but there are limitations on the MailboxSelection parameter. Is there some reason why you can't use this service?


  • Guest
    Reply
    |
    Apr 11, 2024

    I opened a few cases on similar issues where old/unextractable/incomplete messages were not being cleaned up properly in the fileshare and/or DB. We ended up with a couple solutions:


    1. Run SQL from time-to-time against the DB to identify these records, and then run deletes.

    2. We also built global mailbox equivalents to the non-GM SFG BPs MailboxDeleteAllService and MailboxDeleteService.

    3. We also created cron jobs on the server itself to identify directories/files within the shared drive older than x days and to delete them.

    We've built multiple layers to help with the cleanup of data, but it's still not 100% full-proof. It would be nice if GM was smart enough to recognize these scenarios and do similar cleanup.

    1 reply
  • Admin
    Mark Allen
    Reply
    |
    Feb 21, 2024

    Thanks for sharing your idea. I need a little more information to understand your idea.


    In the product today we have several automatic purge schemes:

    • PayloadPurgeJob - Deletes orphaned payloads, or payloads that are no longer referenced by a message, from the local data center.

    • MessagePurgeJob - Deletes incomplete messages.

    • ExpiredPurge - Deletes messages that are no longer extractable


    Our documentation and blog posts on GM purge schemes:


    The first one, PayloadPurgeJob, should be deleting payloads that are no longer referenced by a message. If that isn't working in your case, you may want to contact support to determine if there is a misconfiguration or another issue.


    I'm looking forward to your response. Once I can develop a clear picture of your request, I'll be able to let you know if we can add your idea to our future offering roadmap.