ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Compile and inline resources for ESQL library

Post new topic  Reply to topic Goto page 1, 2  Next
 Compile and inline resources for ESQL library « View previous topic :: View next topic » 
Author Message
goffinf
PostPosted: Mon Dec 03, 2012 4:34 pm    Post subject: Compile and inline resources for ESQL library Reply with quote

Chevalier

Joined: 05 Nov 2005
Posts: 401

Versin: 8.0.0.1

I had been discussing this as part of another thread but I think it's better to separate my question out so it might help others if they are searching for something similar in the future.

I have a Library project. The Library largely consists of collections of reusable ESQL functions and procedures grouped into different schema that relate to their use. There are a couple of subflows but these only reference a few of the ESQL functions.

I had noticed that if I try and deploy this Library using the 'Compile and in-line resources' option that I get a deployment exception which basically states that a called function cannot be found even though I had referenced the schema in which it resides in the PATH statement of the calling ESQL file. Here's an example of the deployment error (BIP2558E):-

Code:

('com.mycompany.messagebroker.soacommon.exceed.cfw.CallExceedAdaptorHTTP_addAdaptorStructureAndSOAPProtocol.Main', '15.41') : Undefined function '''.'getCorrelationID''.   

The program is attempting to call a function which is not defined or is not in the schema path.

Correct the syntax of your ESQL expression in node ''com.mycompany.messagebroker.soacommon.exceed.cfw.CallExceedAdaptorHTTP_addAdaptorStructureAndSOAPProtocol.Main'', around line and column ''15.41'', then redeploy the message flow. 


So here the the function 'getCorrelationID' is apparently not found even though at the top of the calling ESQL file the PATH statement includes the schema in which it resides :-

Code:

PATH com.mycompany.messagebroker.soacommon.misc;


If I switch to deploying the BAR as source (by NOT selecting the 'Compile and in-line resources' option on the 'prepare' tab of the BAR file editor, the BAR *does* deploy successfully.

I originally thought that this must be a bug with the BAR file compilation, but now I am wondering whether it is in fact the behaviour you should expect ?

Choosing 'Compile and in-line resources' would suggest that you have a Message FLOW that is compiled to a CMF and, any ESQL that it references is 'in-lined' within that CMF. But what I have is really just a buch of ESQL functions, some of which make calls to others in other schema. But there is no FLOW that provides a compilation unit into which ESQL would be in-lined, so perhaps this provides a reason why this library MUST be deployed as SOURCE.

A supporting observation. I created another very simple library with 2 ESQL files in different schema each having a single function. The function in one called the function in the other. This compiled without error but when I came to create the BAR file (choosing the 'Compile and in-line resources' option) it contained NO FILES at all. I assume this was for the reason I mentioned above. If I created the BAR file as source, both ESQL files appear in the BAR, and the deploy is successful.

What do you think. Does this explain the behaviour I saw with my original Library and suggest that if you create a Library of reusable ESQL functions then deploying as source is the only option ??

Regards

Fraser.
Back to top
View user's profile Send private message
Esa
PostPosted: Tue Dec 04, 2012 12:19 am    Post subject: Re: Compile and inline resources for ESQL library Reply with quote

Grand Master

Joined: 22 May 2008
Posts: 1387
Location: Finland

goffinf wrote:

What do you think. Does this explain the behaviour I saw with my original Library and suggest that if you create a Library of reusable ESQL functions then deploying as source is the only option ??


Yes, that's exactly how I would expect it to work.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Tue Dec 04, 2012 4:25 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

You might also view this scenario as a reason why it is now possible to actually deploy ESQL independently, without having to make sure that some node actually calls something in each and every ESQL file.
Back to top
View user's profile Send private message
goffinf
PostPosted: Wed Dec 05, 2012 4:59 am    Post subject: Reply with quote

Chevalier

Joined: 05 Nov 2005
Posts: 401

mqjeff wrote:
You might also view this scenario as a reason why it is now possible to actually deploy ESQL independently, without having to make sure that some node actually calls something in each and every ESQL file.


Yes, I take your point but it there appear to be some difficulties here, especially with the Message Broker Project (MBP) type (or perhaps I'm not understanding something).

If I create an MBP to contain my reusable ESQL functions and deploy that MBP as source (as we've established in can't be compiled when there aren't flows that reference all the functions) then indeed the ESQL files will be deployed at the EG level independently and can be updated independently. All good.

But ... If I have another project that is an Application or Library, how can it take advantage of those ESQL functions in the MBP. An Application or Library project can't have a reference to an MBP ??

If I create a Library to contain my reusable ESQL functions then as far as deployment is concerned, it is the whole library that is deployed, not individual ESQL files. Other projects of all types can reference the library so reuse is possible, its just that deployment is of the whole library not individual resources within it.

However ....

If I reference the library from an MBP and lets say that MBP has a subflow (as a v8 .subflow) and that subflow calls one or more of the common functions in my Library of reusable functions, then, when creating the BAR, the referenced ESQL files from the Library will be added (because deployable subflows MUST be packaged as source (not compiled) and hence dependent ESQL source will be added also).

So, you can remove the ESQL files from the common Library which were added to the BAR, but obviously only as long as the common Library is already deployed. And in fact at present if you don't remove them, the target EG abends ! (I will be raising this as a PMR).

If the common Library project includes some re-usable subflows, things get even more confusing. If you have an MBP project with a subflow which also embeds a subflow from the common Library, again, when the BAR is created that reusable subflow is added (and its esql), and if you don't remove it, you get a deployment error stating that the subflow is already deployed.

We are in the process of migrating from v6.1 to v8 and are trying to sort out which project types are best for the flows and other resources we are moving across. So understanding all of these matters is critical. There seem to be less issues if we stick largely with Library or Application project types, but I'm reluctant just to ditch the MBP without properly understanding why.

Comments welcome

Fraser.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Wed Dec 05, 2012 5:15 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

Okay, so the first thing to remember is that in v8, absolutely everything is deployed within an application.

It is either deployed within a NAMED application (i.e. an Application project) , or it is deployed in the DEFAULT application.

No object within an application can reference deployed object that is not included within that application itself.

This is vital and crucial to understand in order to understand how v8 works.

When you define a Library project, and reference that Library from a named application, that Library is compiled and copied into the deployed application space. It is not deployed separately and referenced separately - every application that references that library has it's own private copy.

When you define an MB project and deploy that to the EG, it gets deployed into the default application. It can then only see things that are also deployed to the default application.

If you deploy a Library without referencing ti from an Application, it gets deployed to the default application.

Note that v8.0.0.1 Services are merely flavors of Application, to the best of my knowledge they do not change or alter this container rule.

If you wish to stick with MBPs, then you should completely stick with MBPs and not put your common ESQL into an actual Library. If you want to deploy ESQL without making sure that some function in every ESQL file is actually invoked, then just create a separate bar file that only contains the ESQL files and deploy those directly to the default application.

The reason to abandon the MBP entirely in favor of the Application/Library/Service in v8 is that, in fact, that's simply how things are done in v8. If you are going through the process of migration then part and parcel of that process is migrating your projects into Apps/Libs/Services.

This positions you to take full advantage of all of the features of V8, because they are designed around expecting your code to be packaged that way.

And, again, even if you DON't convert your code to apps/libs/services, you're still using the DEFAULT application anyway, so you might as well face up to it and create applications that make logical sense for your business needs.
Back to top
View user's profile Send private message
goffinf
PostPosted: Wed Dec 05, 2012 6:31 am    Post subject: Reply with quote

Chevalier

Joined: 05 Nov 2005
Posts: 401

mqjeff wrote:

This is vital and crucial to understand in order to understand how v8 works.


Yep get that.

mqjeff wrote:

The reason to abandon the MBP entirely in favor of the Application/Library/Service in v8 is that, in fact, that's simply how things are done in v8. If you are going through the process of migration then part and parcel of that process is migrating your projects into Apps/Libs/Services.

This positions you to take full advantage of all of the features of V8, because they are designed around expecting your code to be packaged that way.

And, again, even if you DON't convert your code to apps/libs/services, you're still using the DEFAULT application anyway, so you might as well face up to it and create applications that make logical sense for your business needs


That's good advice thx.

I was being slightly hesitant based on some earlier advice (actually also from you) which basically went along the lines of '... wait until you have a coherent set of resources before choosing an Application or Library project type to contain them ..'. I am also under some pressure to migrate with the minimum amount of change (i.e. get stuff working as/is before we look at new v8 features). That's not unreasonable, but it looks like getting this bit right is going to make that migration easier.

When converting the project I am testing migration with to a Library along with my common stuff also in a Library, things goes relatively smoothly.

That said, even when using a Library for my migrated project I can get the EG to abend if I forget to take out the references to Libraries that are already deployed from the BAR. Its not at all clear why, so I might raise a PMR for that one.

Cheers

Fraser.
Back to top
View user's profile Send private message
sunny_30
PostPosted: Tue Jul 09, 2013 10:14 am    Post subject: Reply with quote

Master

Joined: 03 Oct 2005
Posts: 258

mqjeff wrote:
Okay, so the first thing to remember is that in v8, absolutely everything is deployed within an application.
It is either deployed within a NAMED application (i.e. an Application project) , or it is deployed in the DEFAULT application.


Sorry to open up an old topic thread.
BUT I don't find this statement to be true.

I have deployed a v8 MessageFlow & I see it IS NOT deployed in a 'default' Application. Infact its deployed as a fully independent Message-Flow with no citing of any Application at all- just similar to v7.

Has anything changed recently in MB v8? Im on v8001
please clarify if Im missing something here..
Back to top
View user's profile Send private message
lancelotlinc
PostPosted: Tue Jul 09, 2013 10:26 am    Post subject: Reply with quote

Jedi Knight

Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA

Yes, alot has changed, even from 8.0.0.1 to 8.0.0.2.

Your V7-style flows are not yet assigned to an Application. Update your toolkit then convert your flows into an Application container.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER
Back to top
View user's profile Send private message Send e-mail
sunny_30
PostPosted: Tue Jul 09, 2013 10:32 am    Post subject: Reply with quote

Master

Joined: 03 Oct 2005
Posts: 258

Yes- I understand that if the v8 flows are moved into an Application container, they do get deployed with Application name.
I also agree that lot changed between 8001 & 8002.

But, from mqjeff's statement above, it looked like, even if the flow isn't deployed in an Application, it will still get deployed in a default Application container and I don't see that happening. May be I misunderstood or missing something, please clarify.
Back to top
View user's profile Send private message
lancelotlinc
PostPosted: Tue Jul 09, 2013 10:34 am    Post subject: Reply with quote

Jedi Knight

Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA

Un-container'd message flows show up in MBE on the EG as flows with no container. Don't try to use the containers in 8 without upgrading and effective level to 8.0.0.2
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER
Back to top
View user's profile Send private message Send e-mail
sunny_30
PostPosted: Tue Jul 09, 2013 10:40 am    Post subject: Reply with quote

Master

Joined: 03 Oct 2005
Posts: 258

lancelotlinc wrote:
Un-container'd message flows show up in MBE on the EG as flows with no container.


So- do you mean that they still have a DEFAULT container which isn't visible.. ?
Back to top
View user's profile Send private message
mqjeff
PostPosted: Tue Jul 09, 2013 10:52 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

sunny_30 wrote:
lancelotlinc wrote:
Un-container'd message flows show up in MBE on the EG as flows with no container.


So- do you mean that they still have a DEFAULT container which isn't visible.. ?


Yes. Anything that is not deployed in an Application container or Service container is deployed to the default application container.

Regardless of that, you still need to move to 8.0.0.2. There are lots of bug fixes that will catch you with your pants down.
Back to top
View user's profile Send private message
sunny_30
PostPosted: Tue Jul 09, 2013 11:37 am    Post subject: Reply with quote

Master

Joined: 03 Oct 2005
Posts: 258

Yes- understood about the upgrade. Its in works.

Back to my Q:
Isn't this "default" Application different from the named-Application in terms of deploying individual flows contained in it, separately ?

Meaning if I have 3 flows in the named Application, the barfile wont let me deploy just the individual flow1 within that Application BUT when flows are deployed w/o any Application container, & even though, internally its getting deployed in the "default" one, doesn't the default container (if it contained multiple such flows in it) let you deploy just one esql/main/subflow individually?
Back to top
View user's profile Send private message
mqjeff
PostPosted: Tue Jul 09, 2013 11:40 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

I don't know if that's a difference in the runtime container or a difference in packaging.
Back to top
View user's profile Send private message
sunny_30
PostPosted: Tue Jul 09, 2013 12:06 pm    Post subject: Reply with quote

Master

Joined: 03 Oct 2005
Posts: 258

Ok - makes sense.. the packaging is currently not letting select individual flows into Application. but even if it did, after deployment, it would completely replace the old deployed named Application, not append/ overwrite flows contained in it. With the invisible 'default' Applications, the bar file obviously lets pick individual flows & after deploying doesn't wipe out the old flows in that container (meaning old flows that were previously deployed into EG w/o a container don't get affected)

mqjeff wrote:
And, again, even if you DON't convert your code to apps/libs/services, you're still using the DEFAULT application anyway, so you might as well face up to it and create applications that make logical sense for your business needs.

This was your previous comment in the post above.
I think there are lot of restrictions in terms of code reusability with using named Applications. Creating applications seem to be more of hindrance than being helpful in such a situation.

The problem Im having right now is that I deployed several flows in a named Application. But its not letting me reference an external MessageFlow Project & not permitting to reuse the ESQL, subflows unless the external flow is brought into the existing Application & to be redeployed all of them, again !

So if no Applications are used, the flows seem to behave like good old v7 individual flows which can be overwritten, especially considering in v8 subflows & esql files can be deployed individually. A separate MFP with reusable code defined in a broker schema (like v7) seem to be a better approach with v8, than containing mainflows into Applications or reusable code into Libraries..

Please let me know your thoughts if you still suggest using Applications &Libraries instead of individual MB projects ?
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Compile and inline resources for ESQL library
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.