DataPower

Hello,

I'm new to DataPower and I'm starting fresh on a new appliance. I find myself creating a lot of objects and I was wondering if there is a common Naming convention pushed by the community.
I looked around the web and most recommend having one but none suggest one.

Thanks in advance.


------------------------------
Yann
------------------------------

Hi Yann,

Welcome to the DataPower Community!  I'm not aware of any published conventions, but just a few thoughts

- First, never create services in the default domain.  Always have services in an application domain.

- I typically have the service name in my service's dependent object names, for example, MPGW service name "Test-MPGW", Front Side Handler name "Test-MPGW-HTTPS-FSH".  I typically will avoid putting the front side handler port number in the object name as they're always subject to change and if the name mismatches reality it can get confusing.

- The policy template editor (drag/drop editor) will name the rules you create with a standard name based on the policy name, for example "Test-MPGW-Policy_rule_27" will be shown when you click on the new rule button.  Before adding any actions to that rule, I will rename the rule to say what direction the rule is and have a better description other than "rule_27", for example "Test-MPGW-Policy_request-healthcheck" for a rule that may be responding to a health check HTTP GET.  Adding actions will have a similar pattern but will use the rule name as the base of the action name.  Unfortunately you don't get the ability to change the action names without updating them in the .cfg file and restarting the domain.

- Another trick I use in the policy editor is I will create a unused rule in the policy that does nothing other than fetch actions of indirectly referenced files.  This would be needed if you had a transformation stylesheet that did a dp:transform or dp:gatewayscript extension function passing in a filename, or a xsl:include's href attribute, etc, and similarly a gatewayscript that would do something similar with a transform.xslt function or a require of a custom module.  The reason for this is that the export of the service to create a zip file to copy this service to other appliances or general software lifecycle purposes will only include those files that are directly referenced by an action, which is what the fetch actions are doing since references within code by themselves don't cause the file to be exported.

Good luck and enjoy working with DataPower!

Steve

Hi Stephen,

Thanks for the tips, Stephen.

------------------------------
Yann
------------------------------

Original Message:
Sent: Thu February 18, 2021 08:54 AM
From: Stephen Linn
Subject: Naming Convention

Hi Yann,

Welcome to the DataPower Community!  I'm not aware of any published conventions, but just a few thoughts

- First, never create services in the default domain.  Always have services in an application domain.

- I typically have the service name in my service's dependent object names, for example, MPGW service name "Test-MPGW", Front Side Handler name "Test-MPGW-HTTPS-FSH".  I typically will avoid putting the front side handler port number in the object name as they're always subject to change and if the name mismatches reality it can get confusing.

- The policy template editor (drag/drop editor) will name the rules you create with a standard name based on the policy name, for example "Test-MPGW-Policy_rule_27" will be shown when you click on the new rule button.  Before adding any actions to that rule, I will rename the rule to say what direction the rule is and have a better description other than "rule_27", for example "Test-MPGW-Policy_request-healthcheck" for a rule that may be responding to a health check HTTP GET.  Adding actions will have a similar pattern but will use the rule name as the base of the action name.  Unfortunately you don't get the ability to change the action names without updating them in the .cfg file and restarting the domain.

- Another trick I use in the policy editor is I will create a unused rule in the policy that does nothing other than fetch actions of indirectly referenced files.  This would be needed if you had a transformation stylesheet that did a dp:transform or dp:gatewayscript extension function passing in a filename, or a xsl:include's href attribute, etc, and similarly a gatewayscript that would do something similar with a transform.xslt function or a require of a custom module.  The reason for this is that the export of the service to create a zip file to copy this service to other appliances or general software lifecycle purposes will only include those files that are directly referenced by an action, which is what the fetch actions are doing since references within code by themselves don't cause the file to be exported.

Good luck and enjoy working with DataPower!

Steve

------------------------------
Stephen Linn

Original Message:
Sent: Wed February 17, 2021 10:50 AM
From: Yann Mathieu
Subject: Naming Convention

Hello,

I'm new to DataPower and I'm starting fresh on a new appliance. I find myself creating a lot of objects and I was wondering if there is a common Naming convention pushed by the community.
I looked around the web and most recommend having one but none suggest one.

Thanks in advance.


------------------------------
Yann
------------------------------

Hi Yann,

In addition to the ones that Stephen listed it might be useful to add version id to object names. It has been a useful practice in few of the cases I've been working with. 

--HP

------------------------------
Hermanni Pernaa
------------------------------

Original Message:
Sent: Wed February 17, 2021 10:50 AM
From: Yann Mathieu
Subject: Naming Convention

Hello,

I'm new to DataPower and I'm starting fresh on a new appliance. I find myself creating a lot of objects and I was wondering if there is a common Naming convention pushed by the community.
I looked around the web and most recommend having one but none suggest one.

Thanks in advance.


------------------------------
Yann
------------------------------

@Steve Linn gives good advice as always!

I've set the "standard" the other way round so I always prefix the object with the type, e.g. "MPGW_Transformer" ​for a Multi-Protocol-Gateway or "XMLFW_Router" for a XML-Firewall.
For "duplicated" objects, e.g. a HTTPS Front-Side-Handler, I add it with the port included like; "FSH_HTTPS_50443", or for MQ with the queuename, "FSH_MQ_MyQueueName". That way I can easily see what the FSH does listen to without having to "open it".

On the Processing Policy rules I am a bit of a slacker and most often only name the Error and Main rule specifically but it might be good to follow a better pattern, especially if the order of the rules is important!

The naming standard can be adopted to all objects, e.g. "Validation Credential" = "VALCRED_xxxxx", "Identification Credential" = "IDCRED_xxxxx" and so on so just make up your own as you go but make sure the rest of your company follows the same pattern! :)

When you've used DP a longer time you'll find that you do a lot of Export/Import and then the naming standard really helps to find the objects you are looking for!

------------------------------
Anders
Enfo Sweden
Sr. Solutions Architect

IBM Champion, Cloud Integration
------------------------------

Original Message:
Sent: Wed February 17, 2021 10:50 AM
From: Yann Mathieu
Subject: Naming Convention

Hello,

I'm new to DataPower and I'm starting fresh on a new appliance. I find myself creating a lot of objects and I was wondering if there is a common Naming convention pushed by the community.
I looked around the web and most recommend having one but none suggest one.

Thanks in advance.


------------------------------
Yann
------------------------------