| Author |
Message
|
| lium |
 Posted: Mon Jan 14, 2013 11:29 am Post subject: deployment time is too long with WMB version 8 application |
 |
|
Disciple
Joined: 17 Jul 2002
Posts: 184
|
I created an application on WMB version 8, which references to a shared library. The library includes a lot of DFDL schemas.
Right now, every time I made a small modification on either ESQL or message flow, I will deploy the change. However, the sharedlibrary will also get deployed even though there is NO change. However, the shared library includes a lot of schemas and therefore makes the deployment very slow. (10 - 20 minutes)
Is there any way I can only deploy the changed ESQL/Message flow without the referenced library?
Thanks, |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Mon Jan 14, 2013 11:41 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jan 14, 2013 12:00 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
| Don't put all your hamburger patties in the same bun. Make your bars more granular. |
And, how, exactly, do you make a v8 application bar file smaller? |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Jan 14, 2013 12:04 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| mqjeff wrote: |
| lancelotlinc wrote: |
| Don't put all your hamburger patties in the same bun. Make your bars more granular. |
And, how, exactly, do you make a v8 application bar file smaller? |
| Grasshopper wrote: |
| Shared library includes a lot of schemas and therefore makes the deployment very slow. What can I do? |
| Kung Fu wrote: |
| Ah, Grasshopper, not to worry. Reduce the number of schemas in the shared library. |
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jan 14, 2013 12:10 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
| mqjeff wrote: |
| lancelotlinc wrote: |
| Don't put all your hamburger patties in the same bun. Make your bars more granular. |
And, how, exactly, do you make a v8 application bar file smaller? |
| Grasshopper wrote: |
| Shared library includes a lot of schemas and therefore makes the deployment very slow. What can I do? |
| Kung Fu wrote: |
| Ah, Grasshopper, not to worry. Reduce the number of schemas in the shared library. |
|
So you're actually suggesting is that they should refactor their shared libraries to be smaller in size, so they can be more selective about which shared libraries they include in their application.
Which may or may not be possible in any way, depending on the interrelationship between the schemas and the source of the schemas.
A v8 application is always fully deployed. There is no way to do a delta deploy of a v8 application. The only way to control the size of the v8 application bar file is to control the size of the resources contained in the v8 application.
The only way to do delta deploys is to NOT use a full v8 application, but instead use the default application in an EG, and create one EG for each application.
Or wait until the lab has caught up with their RFEs and made it possible to share deployed libraries across applications. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Jan 14, 2013 12:17 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| mqjeff wrote: |
| The only way to control the size of the v8 application bar file is to control the size of the resources contained in the v8 application. |
Imagine the perfect hamburger with two meat patties. Three might even be better. But twenty? Very sloppy.
I agree there is room for some more maturity in this area of the toolkit to enable a more intuitive deployment process.
Sometimes being sloppy is good. But it takes longer to eat a hamburger with twenty meat patties than it does to eat a Big Mac.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jan 14, 2013 12:32 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
| mqjeff wrote: |
| The only way to control the size of the v8 application bar file is to control the size of the resources contained in the v8 application. |
Imagine the perfect hamburger with two meat patties. Three might even be better. But twenty? Very sloppy. |
Imagine that you read what I said rather than continuing to attempt a poor metaphor.
Again, the option to refactor the shared libraries into smaller shared libraries with a smaller set of schemas may or may not be available to lium. Those libraries may be built by an entirely separate team based on complicated business requirements. Those DFDL schemas may be heavily normalized such that most of the definitions that are required to process the messages that lium needs to process are scattered across many many schema files. |
|
| Back to top |
|
|
| lium |
| Posted: Mon Jan 14, 2013 1:43 pm Post subject: |
|
|
Disciple
Joined: 17 Jul 2002
Posts: 184
|
Thanks for reply.
Actually, the totally cobol book structures might be up to 100. Right now, I only pick up those shown up in the messages. I think eventually, it would be much more than 20. So this would create a big problem for me.
As mqjeff said, some of the cobol book might reference the others, if possible, we would like to put them together, this is to not break their relationship, but also for easy management.
I used to think of remove reference from application so that the referenced library will not get deployed. However, as you said, the application will do a full deployment, so the dependent library will also get removed once they are not referenced any more.
I also suspect the smaller size libraries. If you break a big library into several small libraries, all of them will be still deployed, so no difference.
mqjeff, could you please tell how to do as you mention as following?
The only way to do delta deploys is to NOT use a full v8 application, but instead use the default application in an EG, and create one EG for each application.
[/quote] |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jan 14, 2013 3:13 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I mean do not create an application project, but put your message flows into regular message flow projects.
Then deploy to the EG. This will deploy to the EG outside of a named application scope into the EG itself. You can then deploy the libraries independently of the message flows.
However, if you need to create isolation between versions of message flows or versions of libraries in use, you need to put them into separate EGs rather than being able to use the isolation provided by the application. |
|
| Back to top |
|
|
| lium |
| Posted: Mon Jan 14, 2013 5:16 pm Post subject: |
|
|
Disciple
Joined: 17 Jul 2002
Posts: 184
|
Thanks, this helps.
I am considering doing this on DEV, and package everything on UAT in Application. |
|
| Back to top |
|
|
|
|
