Skip to Content
avatar image
Former Member

Ability to filter gateway logging and simulate "go lives"...

Dear gurus,

For those of you have attempted to maintain secinfo and reginfo files (and now any proxy and message servicer ACLs) the subject title should be enough said.

The local and internal contexts account for 99% of the starting and registering of external programs. These create a huge amount of racket in the logging and in the case of secinfo dont give you the USER-HOST unless you activate additional filters, which effectively doubles the trace logging file size.

I would like to create a "functionality wishlist" in the wikis for two new features, but first wanted to test the ideas here and see whether there is agreement:

1) gw/ignore_info parameter

A file which allows certain entries not to be logged, particularly the "local" and "internal" HOST and USER-HOST entries which are anyway contained by the authorization conceot for transactions such as STMS and SM69 and SM37 (as well as some function modules which respect the application concepts, such as SXPG FMs).

This would mean one can only log (and have to read...) exceptions which are truely started or registered remotely!

2) gw/simulate_info parameter

A file which can represent the secinfo and reginfo files to show what would have happened if the real files were active.

The problem is that one cannot realistically test and let alone transport the files from DEV to QAS to PROD. You have to take risks when going live in PROD as the partners and jobs and various other dependencies (call backs) only happen there. Customers are very scraed of such Go-Lives regardless of the support offered (I sometimes spend the night clicking on a refresh button...). The ability to simulate the affect of an active secinfo and reginfo would be very cool.

Any support? If I have a few "thumbs up" then I will create a wiki for it after some discussion about whether a better approach is possible.

For sure something needs to be done, as if client systems using outbound gateway registrations fail to accept critical business data which then creates inconsistencies (customers hate that, even the thought of it!) then there is most likely no second chance to secure the gateway or RFC in general again.

Aye or nay or better suggestion?

Cheers,

Julius

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

3 Answers

  • Best Answer
    avatar image
    Former Member
    Nov 23, 2011 at 01:44 PM

    Ayay Captain!

    Great idea!

    There is a lot of customer-friendlyness improvement to be made in that area...

    Just another thing, little bit related. What about a more 'automated' was of going through the logfiles and finding the unique entries and adding them in a firewall-kind-off way by pressing ACCEPT of DENY buttons...

    Add comment
    10|10000 characters needed characters exceeded

  • Nov 22, 2011 at 01:58 AM

    Aye from me, especially as implementing #1 should make the requirement for #2 virtually redundant.

    Add comment
    10|10000 characters needed characters exceeded

    • That's a fair point, retrofitting gateway logging is an "interesting" task.

      I have a client recently do it as part of a greenfield implementation and it was a much easier process (a bit like role design).

  • Nov 22, 2011 at 03:12 AM

    Hi,

    number 2 reminds me SELinux. You can enforce rules or just log violations of rules. Just logging violations helps you to define proper rules and then just switch to enforce mode. I vote for both features.

    Cheers

    Add comment
    10|10000 characters needed characters exceeded