| Author |
Message
|
| paustin_ours |
 Posted: Sat Mar 14, 2015 10:07 pm Post subject: broker schema |
 |
|
Yatiri
Joined: 19 May 2004
Posts: 667
Location: columbus,oh
|
| Wonder what schema really buys us. Our project has about 60 flows and 100 subflows. All the esql files are stored under the same schema. When a BAR file is built all the esql code is compiled into the BAR. Makes me think why we need schema. I understand you have have multiple resources with same name but all of our names are unique. Is there a good documentation on how to use schema the right way? There is just a one page write up on the infocenter about broker schemas so any help you guys can provide is much appreciated. Thanks for your time in advance. |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Sat Mar 14, 2015 10:52 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
This is a god question for a Sunday morning.
I've seen the schema structure used in exactly the same was as is done with Java.
for example
| Code: |
mycompany.co.uk.esb.project.subproject.class
|
My reaction to that is ... 'Broker is NOT Java.'
Maybe at sometime in the furure ESQL will be deprecated and we will all have to use Java everywhere.(thankfully, I will be retired by then)
I suppose there is a programming standard somewhere that mandates this but how does that apply to software/languages that can't handle this sort of structure.
Personally, I use it where I have multiple flows in an application. A simple one level one should suffice in these cases.
YMMV (and probably will).
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| paustin_ours |
| Posted: Sun Mar 15, 2015 5:51 am Post subject: |
|
|
Yatiri
Joined: 19 May 2004
Posts: 667
Location: columbus,oh
|
I have tried with no luck to find any IBM's write up on how to use BROKER SCHEMA  |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Mar 15, 2015 8:51 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
The java analogy with the package is quite good. The broker schema essentially serves to protect the naming of procedures and avoid name clashes across different projects.
Unlike java package names I would advise you to keep the schema names as short and meaningful as possible. Remember they will be part of your deployed name, and nobody likes a name that's a mile long. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| paustin_ours |
| Posted: Sun Mar 15, 2015 11:57 am Post subject: |
|
|
Yatiri
Joined: 19 May 2004
Posts: 667
Location: columbus,oh
|
| it doesn't make sense to have all your project esql files under the same schema does it? I see when I change an unrelated esql file to the message flow that the bar file needs to be rebuilt it shows as altered. Looks like every esql file is compiled and deployed with every flow. |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Sun Mar 15, 2015 4:47 pm Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| fjb_saper wrote: |
| The broker schema essentially serves to protect the naming of procedures and avoid name clashes |
| paustin_ours wrote: |
| it doesn't make sense to have all your project esql files under the same schema does it? |
as far as the objective to have broker schema serves the required purpose for you.
(we use broker schema to have files in a structured way as said, to avoid name clashes., also it will be useful to keep the files in diff broker schema before and after the changes to them to identify which is placed where and which is the most recent one, if the names of those are same).
You may identify the 'Path' column in the .bar file under its Manage tab, for the corresponding .esql file. By default, each ESQL file that is referenced by one or more of your message flows is deployed as an individual resource, and can be accessed by multiple .msgflow files.
Also, what build options do you select when generating a bar file. BAR
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Mar 16, 2015 4:50 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
I describe it as a namespace rather than a schema as I feel that's a better way of covering the variable segrigation that it offers.
A number of converting Java programmers assume it's a package name, and create schemas 20 characters long with period hierarchies.
I let them, laugh when they complain names that long make things cumbersome and ask why they didn't pick something shorter as the site standards recommend. The Trout Of Teaching stings a little but adds value.
YMMV.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| paustin_ours |
| Posted: Mon Mar 16, 2015 6:34 am Post subject: |
|
|
Yatiri
Joined: 19 May 2004
Posts: 667
Location: columbus,oh
|
i have the first two options checked in the bar build.
1. compile and in-line resources
2. remove before rebuild.
do you think this setting is adding to what i see in that entire esql code of the project is compiled and added to each bar file instead of just the flow and esql it needs. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Mar 16, 2015 7:22 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Vitor wrote: |
A number of converting Java programmers assume it's a package name, and create schemas 20 characters long with period hierarchies.
|
Don't you mean 20 levels DEEP....?
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Mar 16, 2015 7:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| smdavies99 wrote: |
| Vitor wrote: |
A number of converting Java programmers assume it's a package name, and create schemas 20 characters long with period hierarchies.
|
Don't you mean 20 levels DEEP....? |
It's Java. I could mean anything.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Mar 17, 2015 4:24 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| paustin_ours wrote: |
i have the first two options checked in the bar build.
1. compile and in-line resources
2. remove before rebuild.
do you think this setting is adding to what i see in that entire esql code of the project is compiled and added to each bar file instead of just the flow and esql it needs. |
It will certainly have an influence. The next question would be: how do you deploy your flows? Individual resources, or applications?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| paustin_ours |
| Posted: Tue Mar 17, 2015 5:18 am Post subject: |
|
|
Yatiri
Joined: 19 May 2004
Posts: 667
Location: columbus,oh
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Mar 17, 2015 6:13 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| paustin_ours wrote: |
| individual resources |
So you are deploying into a default application container.
That has implications:
All .esql files are being shared across all flows.
All .esql files needed by a flow will be redeployed when deploying the flow...
But if you compile as inline, they should all be integrated into the flow.cmf.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
