| Author |
Message
|
| akil |
 Posted: Wed Nov 05, 2014 5:40 am Post subject: IIB9: Application, Library & ESQL Schema |
 |
|
Partisan
Joined: 27 May 2014
Posts: 338
Location: Mumbai
|
Hi
I have a library that has an ESQL file created in the default broker schema.
I have an application that has referenced the library, and has 2 ESQL files, one in the default broker schema and one in a custom schema called cashpoint.
Both of these ESQL files use a function declared in the ESQL file of the library, the function being called is generateTimeStamp.
While everything nicely complines & the BAR gets created, the deployment fails with the following message.
| Code: |
BIP2558E: (cashpoint.SetInvalidMethodError.Main, 12.11) : Undefined function '.generateTimeStamp'.
The program is attempting to call a function which is not defined or is not in the schema path.
|
The error comes only for the ESQL file that is in the custom schema (cashpoint), the file in the default schema does not give any error, and in-fact the deployment goes through if I comment out that line of code that's referencing the common function .
I have tried the following build options:
1. Compile and in-line resources : checked
2. Compile and in-line resources : un-checked.
Neither of them work.
How do I get this to build?
_________________
Regards |
|
| Back to top |
|
 |
| jsware |
| Posted: Thu Nov 06, 2014 5:07 am Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
Is the function in the library in a broker schema?
Try using the PATH statement to reference the broker schema of the library function.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| akil |
| Posted: Thu Nov 06, 2014 5:27 am Post subject: |
|
|
Partisan
Joined: 27 May 2014
Posts: 338
Location: Mumbai
|
The function in the library is in the default schema..
_________________
Regards |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Thu Nov 06, 2014 12:52 pm Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
| akil wrote: |
| The function in the library is in the default schema.. |
The header comment should be followed by a broker schema declaration and the PATH clauses that specify a list of additional schemas to be searched when matching function and procedure calls to their implementations. Do not use the default broker schema. If possible, have the Broker schema defined explicitly.
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| jsware |
| Posted: Thu Nov 06, 2014 12:57 pm Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
And is the library referenced by the project that is failing to find it?
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Nov 06, 2014 1:01 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| jsware wrote: |
| And is the library referenced by the project that is failing to find it? |
I'm not sure it matters. If the function is unqualified by a schema, IIB is going to search the local schema. The only way to convince it not to search the local schema is to use a named schema. |
|
| Back to top |
|
|
| akil |
| Posted: Thu Nov 06, 2014 8:21 pm Post subject: |
|
|
Partisan
Joined: 27 May 2014
Posts: 338
Location: Mumbai
|
Some findings after trying out suggestions posted on the thread:
If I move the ESQL function in the library inside a named schema, it magically works.
If I move the ESQL function back to the default schema, it fails to deploy.
In either of the cases (inside the default schema or named schema), the toolkit is able to find the ESQL as it shows it as part of the intellisense, and it also complies, only the deploy fails.
Does it mean that when writing usable functions within libraries, named schemas should be used instead of the default schema ?
_________________
Regards |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Sun Nov 09, 2014 12:25 pm Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
I always use the user defined broker schemas rather the default broker schema.
In one of the dW documents (you can google it) related to broker schema, it suggests to use the named ones rather the default one.
Hope you understand how the 'Broker schema' works.
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| 6thelement |
| Posted: Sun Nov 30, 2014 3:25 pm Post subject: |
|
|
Apprentice
Joined: 07 Nov 2008
Posts: 30
|
Hello,
Wondering whether we actually need a user defined broker schema in IIB when applications are giving the much needed isolation. May be it was more useful in good old days where multiple different message flows were sharing the same integration server without any clear run time boundary defined.
Rgds.. |
|
| Back to top |
|
|
| stoney |
| Posted: Mon Dec 01, 2014 12:43 am Post subject: |
|
|
Centurion
Joined: 03 Apr 2013
Posts: 140
|
| 6thelement wrote: |
Hello,
Wondering whether we actually need a user defined broker schema in IIB when applications are giving the much needed isolation. May be it was more useful in good old days where multiple different message flows were sharing the same integration server without any clear run time boundary defined.
Rgds.. |
User defined broker schemas are useful with applications that use libraries.
If you have a library containing ESQL routines used by multiple applications, you can store those ESQL routines inside a user defined broker schema.
This isolates those ESQL routines from other ESQL routines in the applications using that library, or in other libraries used by those applications. |
|
| Back to top |
|
|
| 6thelement |
| Posted: Mon Dec 01, 2014 1:22 am Post subject: |
|
|
Apprentice
Joined: 07 Nov 2008
Posts: 30
|
Didn't understand that.
1. Are you saying we should have broker schemas only for libraries? If yes, how does it matter to have the broker schemas. When any library is included inside the application, a copy is made inside the application anyways without any external reference.
2. So for example in a scenario where we have a centralized middle-ware planned to run more than 500 interfaces grouped under lesser number of applications (say 50) - we don't need a broker schema? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Dec 01, 2014 4:06 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
No the main purpose of the schema is to allow the same function with the same interface to be called from different pieces of code for a different result... because they are in a different schema.
This happens mostly in big projects where calling function A from source A requires a different handling than calling function A from source B.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| 6thelement |
| Posted: Mon Dec 01, 2014 4:52 am Post subject: |
|
|
Apprentice
Joined: 07 Nov 2008
Posts: 30
|
Trying to get your point.  So in the example I gave - Do I need to define a broker schema pattern for usage by all the 500 interfaces as a good practice or define broker schema only as a special case. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Dec 01, 2014 6:19 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
By default you should always provide a broker schema. This way there is no confusion from wherever you may call the function or procedure.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| 6thelement |
| Posted: Wed Dec 10, 2014 1:14 pm Post subject: |
|
|
Apprentice
Joined: 07 Nov 2008
Posts: 30
|
Yes. makes sense. But again grouping into applications is providing the necessary isolation already. So what is the possibility of the conflict what you mentioned earlier in this case.
Application One - 10 Services + 2 Libraries - All in default schema.
Application Two - 8 Service + 3 Libraries - All in default schema.
Even if the libraries are shared between application one and application two, each one of them will have their own copy of libraries and so no conflict.
Not sure if I am clear enough |
|
| Back to top |
|
|
|
|
