Variables not retaining values in shell script block while passed through Jenkins job parameter to a Jenkins Library

I am encountering an issue with variables not retaining their values when accessed within the sh block of the Shared Library code. Facing the problem when invoking a Shared Library from a Jenkins Job while passing arguments to the library function.

JENKINS_VERSION : 2.367

Jenkins Job code :

  pipeline {
      agent {
          //  The agent's details
      }
      parameters {
          // Some parameters
      }
      environment {
          WEB_ACL_NAME = "${params.WEBACLNAME}"
          WEB_ACL_SCOPE = 'CLOUDFRONT'
          // ...... Some more env
            
          }
      options {
          disableConcurrentBuilds()
      }
      stages {
          stage('Update Web ACL Configurations') {
              steps {
                  script {
                  updateWebACLConfig WEB_ACL_NAME: "${WEB_ACL_NAME}, "WEB_ACL_SCOPE: "${WEB_ACL_SCOPE}", CUSTOM_RESPONSE_CODE: 500, CONTENT_DATA: "{}" ,  CUSTOM_RESPONSE_BODY_KEY : "custom500"
              }
          }
      }
  }             
  }

Shared Library code (updateWebACLConfig.groovy):

  void call(Map map = [ : ]) {
      // ...
      String WEB_ACL_SCOPE = null;
      String WEB_ACL_NAME = null;
      String CUSTOM_RESPONSE_BODY_KEY = "${map.CUSTOM_RESPONSE_BODY_KEY}"?.trim();
      Integer CUSTOM_RESPONSE_CODE = ${map.CUSTOM_RESPONSE_CODE};
  
      log.info("CUSTOM_RESPONSE_BODY_KEY:$CUSTOM_RESPONSE_BODY_KEY")
      log.info("CUSTOM_RESPONSE_CODE:$CUSTOM_RESPONSE_CODE")
      if (map.WEB_ACL_NAME?.trim() && map.WEB_ACL_DESCRIPTION?.trim() && map.WEB_ACL_RULE_DEFAULT_ACTION?.trim() && map.WEB_ACL_SCOPE?.trim() && map.WEB_ACL_SCOPE_CLOUDFRONT_REGION?.trim() && map.STS_ASSUME_ROLE_ARN?.trim() && map.WEB_ACL_RULES_JSON_FILE_PATH?.trim() && map.VC_SAMPLED_REQUESTS_ENABLED?.trim() && map.VC_CLOUD_WATCH_METRICS_ENABLED?.trim() && map.VC_METRIC_NAME?.trim()) {
          // ...
      } else {
          error("Missing required parameter: WEB_ACL_NAME, WEB_ACL_DESCRIPTION, WEB_ACL_RULE_DEFAULT_ACTION, WEB_ACL_SCOPE, WEB_ACL_SCOPE_CLOUDFRONT_REGION, STS_ASSUME_ROLE_ARN, WEB_ACL_RULES_JSON_FILE_PATH, VC_METRIC_NAME")
      }
  
      sh '''
          echo "Value Custom response body key is  $CUSTOM_RESPONSE_BODY_KEY"
          echo "$CUSTOM_RESPONSE_CODE"
          echo "Trial $WEB_ACL_SCOPE"
          echo "Name of web ACL is $WEB_ACL_NAME"
           ...
      '''
      // ...
  }

I have a Jenkins Job that invokes another file which is Jenkins Library. This pipeline has several fields, In the stages section Within the script block, It invokes the updateWebACLConfig library passing multiple arguments including WEB_ACL_NAME, WEB_ACL_DESCRIPTION, and custom variables such as CUSTOM_RESPONSE_CODE and CUSTOM_RESPONSE_BODY_KEY.

In Shared Library code :
CUSTOM_RESPONSE_BODY_KEY and CUSTOM_RESPONSE_CODE hold the value provided by the Jenkins job at runtime. I have confirmed that the variables hold the correct values by using log.info().

The issue arises when accessing these variables within the sh block using echo. While the values of WEB_ACL_SCOPE and WEB_ACL_NAME are displayed correctly, the values of CUSTOM_RESPONSE_BODY_KEY and CUSTOM_RESPONSE_CODE appear blank.

I have confirmed that the variables are properly defined and assigned values before entering the sh block. There are no special characters or formatting issues in the variable values that could cause this discrepancy.

The Console output of it is as follows

I would appreciate any assistance or insights on how to resolve this issue. Thank you for your support.

Why should e.g. CUSTOM_RESPONSE_BODY_KEY be in the environment of the sh step?
You have added WEB_ACL_SCOPE explicitly in the environment part of your pipeline so it is to be expected that they are available. But not CUSTOM_RESPONSE_BODY_KEY
They are also not extrapolated by groovy as you run your sh step with single quotes.
Try to wrap your shstep with

withEnv(["CUSTOM_RESPONSE_BODY_KEY=$CUSTOM_RESPONSE_BODY_KEY", ...]) {
  sh '''
....
'''
}

The reason for Including CUSTOM_RESPONSE_BODY_KEY in sh step is
Just below that we are using If else block and every time I used to run the code it used to go into the else block
And CUSTOM_RESPONSE_BODY_KEY was used in IF condition only
So to check does CUSTOM_RESPONSE_BODY_KEY really holds the value, for that it is added into the sh step