850_update_bulletin - Progress Sonic Product Update Bulletin 8.5

® 

® 

PROGRESS® 

SONIC® 

Product Update Bulletin 8.5

Progress® Sonic® Product Update Bulletin 8.5 

© 2011 Progress Software Corporation and/or its subsidiaries or affiliates. All rights reserved. 

These materials and all Progress® software products are copyrighted and all rights are reserved by Progress 

Software Corporation. The information in these materials is subject to change without notice, and Progress 

Software Corporation assumes no responsibility for any errors that may appear therein. The references in these 

materials to specific platforms supported are subject to change. 

Actional, Apama, Artix, Business Empowerment, Business Making Progress, DataDirect (and design), DataDirect 

Connect, DataDirect Connect64, DataDirect Technologies, DataDirect XML Converters, DataDirect XQuery, 

DataXtend, Dynamic Routing Architecture, EdgeXtend, Empowerment Center, Fathom, Fuse Mediation Router, 

Fuse Message Broker, Fuse Services Framework, IntelliStream, IONA, Making Software Work Together, 

Mindreef, ObjectStore, OpenEdge, Orbix, PeerDirect, POSSENET, Powered by Progress, PowerTier, Progress, 

Progress DataXtend, Progress Dynamics, Progress Business Empowerment, Progress Empowerment Center, 

Progress Empowerment Program, Progress OpenEdge, Progress Profiles, Progress Results, Progress Software 

Business Making Progress, Progress Software Developers Network, Progress Sonic, ProVision, PS Select, 

Savvion, SequeLink, Shadow, SOAPscope, SOAPStation, Sonic, Sonic ESB, SonicMQ, Sonic Orchestration 

Server, SpeedScript, Stylus Studio, Technical Empowerment, WebSpeed, Xcalia (and design), and Your Software, 

Our Technology-Experience the Connection are registered trademarks of Progress Software Corporation or one of 

its affiliates or subsidiaries in the U.S. and/or other countries. AccelEvent, Apama Dashboard Studio, Apama Event 

Manager, Apama Event Modeler, Apama Event Store, Apama Risk Firewall, AppsAlive, AppServer, ASPen, ASPin-a-Box, 

BusinessEdge, Cache-Forward, CloudEdge, DataDirect Spy, DataDirect SupportLink, Fuse, FuseSource, 

Future Proof, GVAC, High Performance Integration, ObjectStore Inspector, ObjectStore Performance Expert, 

OpenAccess, Orbacus, Pantero, POSSE, ProDataSet, Progress Arcade, Progress CloudEdge, Progress Control 

Tower, Progress ESP Event Manager, Progress ESP Event Modeler, Progress Event Engine, Progress RFID, 

Progress RPM, PSE Pro, SectorAlliance, SeeThinkAct, Shadow z/Services, Shadow z/Direct, Shadow z/Events, 

Shadow z/Presentation, Shadow Studio, SmartBrowser, SmartComponent, SmartDataBrowser, SmartDataObjects, 

SmartDataView, SmartDialog, SmartFolder, SmartFrame, SmartObjects, SmartPanel, SmartQuery, SmartViewer, 

SmartWindow, Sonic Business Integration Suite, Sonic Process Manager, Sonic Collaboration Server, Sonic 

Continuous Availability Architecture, Sonic Database Service, Sonic Workbench, Sonic XML Server, The Brains 

Behind BAM, WebClient, and Who Makes Progress are trademarks or service marks of Progress Software 

Corporation and/or its subsidiaries or affiliates in the U.S. and other countries. Java is a registered trademark of 

Oracle and/or its affiliates. Any other marks contained herein may be trademarks of their respective owners. 

Third Party Acknowledgements: 

Progress Sonic v8.5 incorporates Model Objects Framework v2.0 from ModelObjects Group. Such technology is 

subject to the following terms and conditions: The ModelObjects Group Software License, Version 1.0 - Copyright 

(c) 2000-2001 ModelObjects Group. All rights reserved. Redistribution and use in source and binary forms, with 

or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source 

code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions 

in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the 

documentation and/or other materials provided with the distribution. 3. The end-user documentation included with

the redistribution, if any, must include the following acknowledgement: "This product includes software developed 

by the ModelObjects Group (http://www.modelobjects.com)." Alternatively, this acknowledgement may appear in 

the software itself, if and wherever such third-party acknowledgements normally appear. 4. The name 

"ModelObjects" must not be used to endorse or promote products derived from this software without prior written 

permission. For written permission, please contact djacobs@modelobjects.com. 5. Products derived from this 

software may not be called "ModelObjects", nor may ModelObjects" appear in thier name, without prior written 

permission of the ModelObjects Group. THIS SOFTWARE IS PROVIDED "AS IS" AND ANY EXPRESSED OR 

IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 

MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT 

SHALL THE MODEL OBJECTS GROUP OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, 

INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, 

BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 

DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF 

LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR 

OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF 

THE POSSIBILITY OF SUCH DAMAGE. 

Progress Sonic v8.5 incorporates OpenSAML Java Distribution v1.0.1. Such technology is subject to the following 

terms and conditions: The OpenSAML License, Version 1. Copyright (c) 2002 - University Corporation for 

Advanced Internet Development, Inc. All rights reserved. Redistribution and use in source and binary forms, with 

or without modification, are permitted provided that the following conditions are met: Redistributions of source 

code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in 

binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the 

documentation and/or other materials provided with the distribution, if any, must include the following 

acknowledgment: "This product includes software developed by the University Corporation for Advanced Internet 

Development (http://www.ucaid.edu)Internet2 Project. Alternately, this acknowledegement may appear in the 

software itself, if and wherever such third-party acknowledgments normally appear. Neither the name of 

OpenSAML nor the names of its contributors, nor Internet2, nor the University Corporation for Advanced Internet 

Development, Inc., nor UCAID may be used to endorse or promote products derived from this software without 

specific prior written permission. For written permission, please contact opensaml@opensaml.org. Products 

derived from this software may not be called OpenSAML, Internet2, UCAID, or the University Corporation for 

Advanced Internet Development, nor may OpenSAML appear in their name, without prior written permission of 

the University Corporation for Advanced Internet Development. THIS SOFTWARE IS PROVIDED BY THE 

COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND WITH ALL FAULTS. ANY EXPRESS OR 


MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT ARE 

DISCLAIMED AND THE ENTIRE RISK OF SATISFACTORY QUALITY, PERFORMANCE, ACCURACY, 

AND EFFORT IS WITH LICENSEE. IN NO EVENT SHALL THE COPYRIGHT OWNER, CONTRIBUTORS 

OR THE UNIVERSITY CORPORATION FOR ADVANCED INTERNET DEVELOPMENT, INC. BE LIABLE 

FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 

DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 

SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED 

AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT

(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS 

SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 

Progress Sonic v8.5 incorporates BasicLogin.java, SimpleCallbackHandler.java, SimplePasswordUser.java, 

SampleLoginModule.java, SamplePrincipal.java from Sun Microsystems, Inc. These technologies are subject to 

the following terms and conditions: Copyright 2000-2002 Sun Microsystems, Inc. All Rights Reserved. 

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the 

following conditions are met: -Redistributions of source code must retain the above copyright notice, this list of 

conditions and the following disclaimer. -Redistribution in binary form must reproduce the above copyright notice, 

this list of conditions and the following disclaimer in the documentation and/or other materials provided with the 

distribution. Neither the name of Sun Microsystems, Inc. or the names of contributors may be used to endorse or 

promote products derived from this software without specific prior written permission. This software is provided 

"AS IS," without a warranty of any kind. ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS 

AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR 

A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND ITS 

LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES OR LIABILITIES SUFFERED BY LICENSEE 

AS A RESULT OF OR RELATING TO USE, MODIFICATION OR DISTRIBUTION OF THE SOFTWARE 

OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS BE LIABLE FOR ANY LOST 

REVENUE, PROFIT OR DATA, OR FOR DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL, 

INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF 

LIABILITY, ARISING OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS 

BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. You acknowledge that Software is not 

designed, licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility. 

Progress Sonic v8.5 incorporates Saxon XSLT and XQuery Processor v8.9.0.4 from Saxonica Limited 

(http://www.saxonica.com/) which is available from SourceForge (http://sourceforge.net/projects/saxon/). PSC 

will, at Licensee's request, provide copies of the source code for this third party technology, including 

modifications, if any, made by PSC. PSC may charge reasonable shipping and handling charges for such 

distribution. Licensee may also obtain the source code through http://communities.progress.com/pcom/docs/DOC- 

16051 by following the instructions set forth therein. - Mozilla Public License Version 1.0 (the "License"); you may 

not use this file except in compliance with the License. You may obtain a copy of the License at 

http://www.mozilla.org/MPL. Software distributed under the License is distributed on an "AS IS" basis, 

WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License for the specific language 

governing rights and limitations under the License. The Original Code of Saxon comprises all those components 

which are not explicitly attributed to other parties. The Initial Developer of the Original Code is Michael Kay. Until 

February 2001 Michael Kay was an employee of International Computers Limited (now part of Fujitsu Limited), 

and original code developed during that time was released under this license by permission from International 

Computers Limited. From February 2001 until February 2004 Michael Kay was an employee of Software AG, and 

code developed during that time was released under this license by permission from Software AG, acting as a 

"Contributor". Subsequent code has been developed by Saxonica Limited, of which Michael Kay is a Director, 

again acting as a "Contributor". A small number of modules, or enhancements to modules, have been developed by 

other individuals (either written specially for Saxon, or incorporated into Saxon having initially been released as 

part of another open source product). Such contributions are acknowledged individually in comments attached to

the relevant code modules. All Rights Reserved. 

Progress Sonic v8.5 incorporates Mozilla Rhino v1.5R3. The contents of this file are subject to the Netscape Public 

License Version 1.1 (the "License"); you may not use this file except in compliance with the License. You may 

obtain a copy of the License at http://www.mozilla.org/NPL/. Software distributed under the License is distributed 

on an "AS IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License for the 

specific language governing rights and limitations under the License. The Original Code is Mozilla Communicator 

client code, released March 31, 1998. The Initial Developer of the Original Code is Netscape Communications 

Corporation. Portions created by Netscape are Copyright (C) 1998-1999 Netscape Communications Corporation. 

All Rights Reserved. PSC will, at Licensee's request, provide copies of the source code for this third party 

technology, including modifications, if any, made by PSC. PSC may charge reasonable shipping and handling 

charges for such distribution. Licensee may also obtain the source code through 

http://communities.progress.com/pcom/docs/DOC-16051 by following the instructions set forth therein. 

Progress Sonic v8.5 incorporates Apache Ant-Contrib 1.0B3. Such technology is subject to the following terms 

and conditions: The Apache Software License, Version 1.1 - Copyright (c) 2001-2003 Ant-Contrib project. All 

rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted 

provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright 

notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the 

above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other 

materials provided with the distribution. 3. The end-user documentation included with the redistribution, if any, 

must include the following acknowlegement: "This product includes software developed by the Ant-Contrib 

project (http://sourceforge.net/projects/ant-contrib)." Alternately, this acknowlegement may appear in the software 

itself, if and wherever such third-party acknowlegements normally appear. 4. The name Ant-Contrib must not be 

used to endorse or promote products derived from this software without prior written permission. For written 

permission, please contact ant-contrib-developers@lists.sourceforge.net. 5. Products derived from this software 

may not be called "Ant-Contrib" nor may "Ant-Contrib" appear in their names without prior written permission of 

the Ant-Contrib project. THIS SOFTWARE IS PROVIDED `ÀS IS'' AND ANY EXPRESSED OR IMPLIED 

WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 


SHALL THE ANT-CONTRIB PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, 

INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, 

BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 

DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF 

LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR 

OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF 

THE POSSIBILITY OF SUCH DAMAGE. 

Progress Sonic v8.5 incorporates Xalan Java XSLT Parser v2.4.1 from the Apache Foundation. Such technology 

is subject to the following terms and conditions: The Apache Software License, Version 1.1 - Copyright (c) 1999 

The Apache Software Foundation. All rights reserved. Redistribution and use in source and binary forms, with or 

without modification, are permitted provided that the following conditions are met: 1. Redistributions of source 

code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions 

in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the

documentation and/or other materials provided with the distribution. 3. The end-user documentation included with 

the redistribution, if any, must include the following acknowledgment: "This product includes software developed 

by the Apache Software Foundation (http://www.apache.org/)." Alternately, this acknowledgment may appear in 

the software itself, if and wherever such third-party acknowledgments normally appear. 4. The names "Xalan" and 

"Apache Software Foundation" must not be used to endorse or promote products derived from this software without 

prior written permission. For written permission, please contact apache@apache.org. 5. Products derived from this 

software may not be called "Apache", nor may "Apache" appear in their name, without prior written permission of 

the Apache Software Foundation. THIS SOFTWARE IS PROVIDED `ÀS IS'' AND ANY EXPRESSED OR 



SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY 

DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES 

(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS 

OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 

THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING 

NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN 

IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 

========================================== 

This software consists of voluntary contributions made by many individuals on behalf of the Apache Software 

Foundation and was originally based on software copyright (c) 1999, Lotus Development Corporation., 

http://www.lotus.com. For more information on the Apache Software Foundation, please see 

(http://www.apache.org/). 

Progress Sonic v8.5 incorporates Xerces v2.6.2 from the Apache Foundation. Such technology is subject to the 

following terms and conditions: The Apache Software License, Version 1.1 - Copyright (c) 1999-2004 The Apache 

Software Foundation. All rights reserved. Redistribution and use in source and binary forms, with or without 

modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must 

retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary 

form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the 

documentation and/or other materials provided with the distribution. 3. The end-user documentation included with 

the redistribution, if any, must include the following acknowledgment: "This product includes software developed 

by the Apache Software Foundation (http://www.apache.org/)." Alternately, this acknowledgment may appear in 

the software itself, if and wherever such third-party acknowledgments normally appear. 4. The names "Xerces" and 



software may not be called "Apache", nor may "Apache" appear in their name, without prior written permission of 

the Apache Software Foundation. THIS SOFTWARE IS PROVIDED `ÀS IS'' AND ANY EXPRESSED OR 





(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS





================================================================ 


Foundation and was originally based on software copyright (c) 1999, International Business Machines, Inc., 

http://www.ibm.com. For more information on the Apache Software Foundation, please see 


Progress Sonic v8.5 incorporates RSS4J v0.9.2. Such technology is subject to the following terms and conditions: 

Copyright (c) 1999-2002 ChurchillObjects.com All rights reserved. Redistribution and use in source and binary 

forms, with or without modification, are permitted provided that the following conditions are met: Redistributions 

of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 

Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following 

disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of the 

copyright holder nor the names of its contributors may be used to endorse or promote products derived from this 

software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT 

HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, 

INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND 

FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR 

CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, 

OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF 

SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 

INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN 

CONTRACT, STRICT LIABILITY, OR TORT, INC 

Progress Sonic v8.5 incorporates Crimson v1.1.3. Such technology is subject to the following terms and 

conditions: The Apache Software License, Version 1.1. Copyright (c) 1999-2003 The Apache Software 

Foundation. All rights reserved. Redistribution and use in source and binary forms, with or without modification, 

are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the 

above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must 

reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation 

and/or other materials provided with the distribution. 3. The end-user documentation included with the 

redistribution, if any, must include the following acknowledgment: "This product includes software developed by 

the * Apache Software Foundation (http://www.apache.org/)." Alternately, this acknowledgment may appear in 

the software itself, if and wherever such third-party acknowledgments normally appear. 4. The names "Xerces" and 



software may not be called "Apache", nor may "Apache" appear in their name, without prior written * permission 

of the Apache Software Foundation. THIS SOFTWARE IS PROVIDED `ÀS IS'' AND ANY EXPRESSED OR 


MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT




OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY 




==================================================================== 


Foundation and was * originally based on software copyright (c) 1999, International * Business Machines, Inc., 

http://www.ibm.com. For more * information on the Apache Software Foundation, please see * 


Progress Sonic v8.5 incorporates Jing 20030619 and Trang 20030619. Such technology is subject to the following 

terms and conditions: Copyright (c) 2002, 2003 Thai Open Source Software Center Ltd. All rights reserved. 

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the 

following conditions are met: Redistributions of source code must retain the above copyright notice, this list of 

conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, 

this list of conditions and the following disclaimer in the documentation and/or other materials provided with the 

distribution. Neither the name of the Thai Open Source Software Center Ltd nor the names of its contributors may 

be used to endorse or promote products derived from this software without specific prior written permission. THIS 

SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY 

EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED 

WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 

DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY 







Progress Sonic v8.5 incorporates RSSUTILS v1.1. Such technology is subject to the following terms and 

conditions: Copyright 2003 Sun Microsystems, Inc. ALL RIGHTS RESERVED Use of this software is authorized 

pursuant to the terms of the license found at http://developer.java.sun.com/berkeley_license.html Copyright 2003 

Sun Microsystems, Inc. All Rights Reserved. Redistribution and use in source and binary forms, with or without 

modification, are permitted provided that the following conditions are met: 

-Redistribution of source code must retain the above copyright notice, this list of conditions and the following 

disclaimer. 

-Redistribution in binary form must reproduce the above copyright notice, this list of conditions and the following 

disclaimer in the documentation and/or other materials provided with the distribution. 

Neither the name of Sun Microsystems, Inc. or the names of contributors may be used to endorse or promote

products derived from this software without specific prior written permission. This software is provided "AS IS," 

without a warranty of any kind. ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND 

WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A 

PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN MICROSYSTEMS, 

INC. ("SUN") AND ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY 

LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THIS SOFTWARE OR ITS 

DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, 

PROFIT OR DATA, OR FOR DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR 

PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, 

ARISING OUT OF THE USE OF OR INABILITY TO USE THIS SOFTWARE, EVEN IF SUN HAS BEEN 

ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. You acknowledge that this software is not designed, 

licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility. 

Progress Sonic v8.5 incorporates DSTC Xs3P version 1.1 from DSTC Pty Ltd. PSC will, at Licensee's request, 

provide copies of the source code for this third party technology, including modifications, if any, made by PSC. 

PSC may charge reasonable shipping and handling charges for such distribution. Licensee may also obtain the 

source code through http://communities.progress.com/pcom/docs/DOC-16051 by following the instructions set 

forth therein. - DSTC Public License. The contents of this file are subject to the DSTC Public License Version 1.1 

(the 'License') (provided herein); you may not use this file except in compliance with the License. Software 

distributed under the License is distributed on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, either 

express or implied. See the License for the specific language governing rights and limitations under the License. 

The Original Code is xs3p. The Initial Developer of the Original Code is DSTC. Portions created by DSTC are 

Copyright (c) 2001, 2002 DSTC Pty Ltd. All Rights Reserved. 

August 2011

Contents 

Chapter 1: Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

Accessing Progress Sonic 8.5 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

Installing Progress Sonic 8.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

Supported Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

Chapter 2: What’s new and changed in Sonic 8.5 . . . . . . . . . . . . . . . . . . . . 19 

Improvements for Responsive Business Integration: Sonic and DataXtend SI. . . . . . . . . . . . . . . . . . 20 

Improvements for Responsive Business Integration: Sonic and Actional. . . . . . . . . . . . . . . . . . . . . . 27 

What’s Also New in Sonic ESB and Sonic Workbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 

What’s New in SonicMQ and Management Framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 

What’s New in Sonic Deployment Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 

What’s Changed in Sonic 8.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 

Chapter 3: What was new and changed in prior Version 8 releases69 

Sonic Installer and Launcher features in 8.0.x. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 

SonicMQ and Management Framework features in 8.0.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 

Sonic ESB and Workbench features in 8.0.x. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 

Sonic Deployment Manager features in 8.0.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 

Chapter 4: What was new and changed in 7.5 and 7.6 releases . . . 129 

SonicMQ and Managememt Framework features in Version 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 

Sonic ESB and Workbench features in Version 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 

Chapter 5: Learning More About the Progress Sonic Products . . . 161 

Progress Sonic Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 

Progress Sonic Infocenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 

Progress Sonic Education and Training. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 

Progress Software Developers Network (PSDN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 

Progress Sonic Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 

Progress Sonic Evaluation Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 

Progress Sonic Update Bulletin 8.5 11

Contents 

12 Progress Sonic Update Bulletin 8.5

Chapter 1 Overview 

This is Progress Sonic 8.5, a point release that contains new features that enhance the 

product as well feature requests and issues reported by customers. 

Progress Sonic is delivered in three installers: 

● Progress Sonic Installer sets up Sonic 8.5 development environments, deployment 

Domain Managers, Sonic Deployment Manager, and administrative tools. The utilities 

that upgrade from 7.5, 7.6, and 8.0 Domain Managers are included. When downloaded, 

unpack it. Installer requires a 1.5 or 1.6 JVM on UNIX and Linux machines to run the 

installer; it can use and install its preferred 1.6 JVM on Windows. Run install.exe 

(Windows) or install.bin (UNIX, Linux.) 

● Progress Sonic Container Launcher installs lightweight resources on systems that run 

Sonic containers, and the utilities for upgrading Sonic 7.5 and 7.6 installations. A 

Launcher installation will be dynamically upgraded and updated by the domains to 

which its containers connect. When downloaded, unpack it. Installer requires a 1.5 or 

1.6 JVM on UNIX and Linux machines to run the installer; it can use and install its 

preferred 16 JVM on Windows. Run install_container_launcher.exe (Windows) or 

install_container_launcher.bin (UNIX, Linux.) 

● Progress Sonic Updater, when available, advances a Sonic Installer location to the 

Updater's version, typically a Service Pack. Service Packs are cumulative so if you 

skipped a service pack, a higher version will include all changes in earlier Service 

Packs. When downloaded, unpack it. Updater requires a 1.5 or 1.6 JVM to run the 

installer, which should be the JVM that supports the installation you intend to update. 

Confirm that the JVM is on the path before you launch the updater. Run install.exe 

(Windows) or install.bin (UNIX, Linux.) 

Download packages are available at the Progress Electronic Software Download (ESD) site 

for additional SonicMQ clients (C, C++, COM, and .NET) and JCA Resource Adapters for 

JBoss, WebSphere, and WebLogic. 


Chapter 1: Overview 

Accessing Progress Sonic 8.5 Documentation 

Sonic 8.5 products are installed with a welcome page at their installation root for access 

to Progress resources and documentation. You can access Sonic 8.5 documentation at its 

remote site. See the downloads page at the remote site for documentation packages and 

archives. Take time to review the release notes list of known issues, and—for current 

customers—a listing of the resolved issues in this release. 

Installing Progress Sonic 8.5 

The following procedures provide the general idea of how new and existing Sonic users 

create Sonic product installations in release 8.5. Open the Progress Sonic Installation and 

Upgrade Guide for detailed instructions on installing, and upgrading installations as well 

as information about silent installations. 

◆ If You Are New to Sonic... 

1. Use the Sonic Installer 8.5 to establish each development environment—Sonic ESB 

or SonicMQ Development—and then start its Domain Manager. 

2. Use the Sonic Installer 8.5 to establish each deployment environment (Domain 

Manager), and then start its Domain Manager. 

3. Use the Sonic Installer 8.5 to distribute just Administration Tools. 

4. Use the Container Launcher Installer 8.5 to enable each distributed system to connect 

and run containers in one of your installed domains. 

5. Unpack downloaded 8.5 C clients, .NET client, and JCA adapters on development 

and distributed deployment systems. 

◆ If You Are Upgrading a Sonic 8.0 Topology... 

1. Start each SonicMQ development or deployment Domain Manager (for ESB 

development, stop everything), stop all associated tools, and then run the Sonic 

Installer pointing to the Progress Sonic Domain Manager’s installation location. 

2. Stop tools in each Administration Tools installation, and then run the Sonic Installer 

to install the latest tools. 

3. Unpack downloaded 8.5 C clients, .NET client, and JCA adapters in a new location 

on development and deployment systems, and then use them to run the clients. 

Open the Progress Sonic Installation and Upgrade Guide chapter “Upgrading from 7.5 or 

7.6 to Sonic 8.5” for detailed procedures for basic upgrades as well as zero-downtime 


Installing Progress Sonic 8.5 

upgrades for replicated brokers, clusters, and fault-tolerant management frameworks. You 

might also want to review the resolved issues in the Sonic 8.5.0 release notes. 

◆ If You Are Upgrading a Sonic 7.5 or 7.6 Topology... 

1. Use the Sonic Installer 8.5 to establish each development environment—Sonic 

Workbench or SonicMQ Development—on a machine with a corresponding version 

7 installation, but do not configure the installation. Start the version 7 Domain 

Manager, and then perform the upgrade. 

2. Use the Sonic Installer 8.5 to establish each deployment environment (Domain 

Manager) on a machine with a corresponding version 7 installation, but do not 

configure the installation. Start the version 7 Domain Manager, and then perform the 

upgrade. 

3. Use the Sonic Installer 8.5 to distribute just Administration Tools to administrator 

machines. 

4. Use the Container Launcher Installer 8.5 to upgrade each distributed system that has 

a version 7 deployment. Then perform the upgrade of that location to 8.5 and 

connection to the 8.5 Domain Manager. 

5. Unpack downloaded 8.5 C clients, .NET client, and JCA adapters on development 

and distributed deployment systems, and then use them to run the clients. You should 

not have to recompile applications. 

Open the Progress Sonic Installation and Upgrade Guide chapter “Upgrading Version 8 

Domains and Tools7.5 or 7.6 to Sonic 8.5” for detailed procedures for basic upgrades as 

well as zero-downtime upgrades for replicated brokers, clusters, and fault-tolerant 

management frameworks. You might also want to review the resolved issues in the Sonic 

8.5.0 release notes. 



Supported Standards 

Standards supported in Progress Sonic 8.5 include the following: 

Group Standard Version 

Web Services REST 

SOAP 1.1 

SOAP 1.2 

SOAP with Attachments 2000 

WSDL 1.1 

WS-BP 1.0 

WS-Addressing 

WS-Policy 2004 

WS-Policy 1.2 

WS-Security 1.0 

WS-RM 

JAX-WS 2.1 

JAX-RS 1.0 

BPEL 2.0 

MTOM 2005 

Transports and Protocols JMS 1.0/1.1 

HTTP 1.0/1.1 

HTTPS 


Platforms 

Sonic advanced the supported JVMs and default sizing of system resources. 

Java Runtime Environment 

Supported Standards 

See the Progress Sonic supported platforms page for 8.5 at www.progress.com/sonic. 

Be sure the installer versions and tools use 32-bit or 64-bit JVMs and downloads as 

appropriate to target machine architectures. 

Java heap size settings 

The default Java heap initial and max size settings on management containers are: 

-Xms64m -Xmx512m 

Note Upgrades or deployments on new machines might experience issues with JVM memory 

usage. Be sure to test applications on anticipated machine types and JVMs. 

Compatibilities with Other Progress Products 

This release of Sonic requires that associated Progress products use specific versions: 

● Actional — Management servers and agents must be release 8.2.3 

● Dataxtend SI — Must be at release 8.5 and its Eclipse at 3.6 

Install or upgrade these products to ensure compatibility. 




Chapter 2 What’s new and changed in Sonic 8.5 

This chapter describes new and enhanced functionality in release 8.5 of the Progress 

Sonic products in the following sections: 

● “Improvements for Responsive Business Integration: Sonic and DataXtend SI” 

● “Improvements for Responsive Business Integration: Sonic and Actional” 

● “What’s Also New in Sonic ESB and Sonic Workbench” 

● “What’s New in SonicMQ and Management Framework” 

● “What’s New in Sonic Deployment Manager” 

● “What’s Changed in Sonic 8.5” 


Chapter 2: What’s new and changed in Sonic 8.5 

Improvements for Responsive Business Integration: 

Sonic and DataXtend SI 

Progress® Sonic® 8.5 introduces the following features to improve Progress® 

DataXtend® Semantic Integrator (SI) 8.5 integration: 

● “Improved deployment option to manage external generated packages” 

● “DataXtend SI Invocation Support for Multi-part Messages” 

● “Invoking a data service operation from a Sonic ESB itinerary” 

Improved deployment option to manage external generated 

packages 

The enhanced packaging usability feature from DataXtend SI enables you to package the 

required artifacts as a Sonic Archive (XAR) file. You can also generate a package with 

multiple services in a single archive. The package is then uploaded to the Sonic Directory 

Services to make the exposed DataXtend SI Services available in ESB. 

Sonic 8.5 provides an improved deploy folder for a Sonic project in Workbench to 

manage external generated packages. This enables you to manage integration with other 

products, such as DataXtend SI, in a better way. You can also use this new deployment 

option to manage any other XAR files. You can now: 

● “Expand the XAR archives” on page 21 

● “Customize the XAR files or XAR folder contents for Sonic deployments by setting 

flags such as ignore or overwrite” on page 21 

● “Create logical link with the external source XAR files” on page 21 

● “Notify when a source XAR has been modified” on page 22 


Improvements for Responsive Business Integration: Sonic and DataXtend SI 

Expand the XAR archives 

In the Project Explorer view, click the icon on the left hand side of the XAR file to 

expand it and view its details, as shown:. 

Customize the XAR files or XAR folder contents for Sonic deployments by 

setting flags such as ignore or overwrite 

You can upload the XAR files to the Directory Service from the Sonic Workbench. Before 

uploading the XAR files, you can define the rules for uploading the XAR files using the 

overwrite, ignore or reset option. You can right-click the artifacts to select the Overwrite 

Existing option to overwrite the available artifacts and provide the latest copy of the 

service configuration from XAR based on the nature of changes encountered for the 

Service Configuration file. You can also right-click the artifacts and select the Ignore 

option if you want to ignore an existing file during upload. 

If you execute any ignore or overwrite action, an import properties file is created by Sonic 

Workbench if the properties file does not exist and you can see the correct status of the 

configured elements. By default, no properties file is present and Sonic Workbench 

retains its overwriting behavior during upload. 

Create logical link with the external source XAR files 

When you are working with DataXtend SI and Sonic in the same Eclipse installation and 

in the same workspace, you can create a logical link to the XAR file in the DataXtend SI 

project directory’s deployable folder. If you re-export the file in the SI Workbench, the 

Sonic project automatically has the updated XAR file. However, if the XAR file is 

updated in the DataXtend SI project, you will need to re-upload it and restart any 

containers in which its data services are deployed. The Copy Deploy Archive into deploy 



folder checkbox indicates whether to copy the selected archive or create a logical link to 

it. Clear the checkbox to create the logical link. 

Notify when a source XAR has been modified 

When a DataXtend SI XAR is changed or is regenerated while linking the XAR using the 

Workspace link, a gray icon is added on the XAR and deploy folder. When a XAR folder 

is linked to a local file system and the contents in the local file system change, you must 

refresh the project or deploy folder to see the modifications. You must explicitly upload 

the XAR file again to push the modified contents to Directory Services. 

Invoking a Typed Service Instance from a Sonic ESB Itinerary 

This feature provides an interface to be associated with a service configuration. It also 

provides development-time access to the interface to facilitate creating an invocation step. 

Sonic 8.5 has introduced a notion of Typed Services wherein a Service Instance will have 

a typed interface. DataXtend SI service is rewritten as a typed service. 

You can retrieve an initialized Typed Service instance ESBDL contract from its 

configuration (XQServiceConfig) in the DS. A Typed Service Instance has many 

operations available. The interface of each of these operations can be retrieved from its 

ESBDL. For invoking a Typed Service in Sonic ESB Itinerary, you must: 

● Configure a service step to invoke the Typed Service Instance 

● Identify the Typed Service Operation 

● Map from in-flight process message to the service invocation parameters. On the 

service return side, map from service output/fault parameters to the next in-flight 

process message. See “DataXtend SI Invocation Support for Multi-part Messages” on 

page 24. 



Configuring a service step to invoke Typed Service Instance 

In addition to the standard way of configuring a service step in ESB Itinerary, Sonic 8.5 

provides an enhanced Project Explorer View, to have all the service instances listed under 

the Domain node. For typed services such as, DataXtend SI Service, you can further 

expand the service instance node, to view the list of available operations. Drag and drop 

on editor canvas is enabled for both service instance & operation nodes. When you dragand-drop 

a service instance or operation, a new service step is created & configured for 

that particular service instance and operation. 

The following screen capture displays a service step in the process itinerary when you 

drag-and-drop a service operation to the process itinerary: 

The SI decorator indicates that it is a DataXtend SI data service. 



Identifying a DataXtend SI Service Operation 

Sonic 8.5 provides a Choose an Operation dialog for an operation ID to list all the 

available operations for the given service instance. From this list, you can select the 

operation to invoke. With the operation ID set, mapping pages is set/reset with the 

interface parameters defined for the given operation. You can also map to/from these 

interface parameters. 

The operation ID that you want to invoke is persisted to the ESB process as a runtime 

parameter of type string. 

Operation ID is persisted as a string having the following pattern: 

{interfaceName}.{operationName}. If interface name is not available Default will be 

appended to the operation name instead of interface name. 

DataXtend SI Invocation Support for Multi-part Messages 

This feature lets you configure the DataXtend SI data service operation to return all values 

and map these values into multi-part messages with appropriate content ID and type 

information. 

A DataXtend SI data service operation can return an arbitrary collection of values in 

addition to the defined output parameters. These collections should be mapped to new 

parts, headers, and process context properties to compose the XQmessage with appropriate 

content ID and type information. To support this type of mapping, Sonic extends ESBDL 

definition to include support for collection parameters. That is, the interface parameter, if 



marked as "collection = true", represents a collection of values and is rendered as 

parameters[] {xq:paramHolderType}. In the response mapping page, you can define a 

mapping rule for such interface parameters and state whether the collection of values are 

to be added as: 

● New Message Parts 

● New Message Headers 

● New Process Context Properties 

As part of the DataXtend SI service, the typed service works on the request interface 

parameters and set the output context that is output parameters from service context. You 

should ensure that these output parameters are propagated to the next in-flight process 

message; that is, the message going out of the service. To achieve this, you must define 

response mapping rules from service output parameters to next in-flight process message 

constructs; that is, headers, parts, and process context properties. In the event of a service 

fault, XQmessage is added to the service fault box and the fault context is set; that is, fault 

parameters for the given operation are specified. You must define fault mapping rules to 

ensure the fault parameters are propagated in the fault message. 

In the mapping pages, the mapping rule for interface parameter with a collection of values 

is displayed. However, at the time of process run, this mapping rule is evaluated for each 

collection element. This is indicated to runtime by adding the following syntax to source 

participant expression: ${esbdl.output'purchaseOrders'.each} 

On the target side, pattern/expression is evaluated for every collection element and 

generates a unique identifier for the given XQMessage construct type (Part, Header, and 

Process Context property). This construct is initialized with the service response 

parameter value (after applying transformation actions). 

You can also configure the mapping rule with transformation details. This transformation 

action is applied to each element in the collection. For configuring transformation action, 

all supported transformation actions are listed. You must correctly configure the 

transformation actions. Also, because the source parameter is a collection of unknown 

values, configured transformation action might or might not be applicable for every 

element in the collection. You can further configure transformation details for the 

mapping rule. Available transformation actions are filtered on the basis of type and 

content type of source interface parameters. 

Sonic 8.5 has changed the following dialog boxes to provide for the collection values: 

● Mapping Rule Participants dialog box — While specifying the target, 

pattern/expression is evaluated for every collection element and an unique identifier 

is generated for the given XQMessage construct type (Part, Header, and Process Context 



property). This construct is initialized with the service response parameter value 

(after applying transformation actions). 

● Expression dialog box— In the response mapping page, Sonic 8.5 lets you define a 

mapping rule for interface parameters and state whether the collection of values are 

to be added as Header (Pattern), Message (Pattern), or Process Context (Pattern): 

Invoking a data service operation from a Sonic ESB itinerary 

A DataXtend SI data service provides an interface of operations that the development 

tools can use to facilitate creating an invocation step. 

For more information, see Chapter 10 “Getting started with Sonic ESB and DataXtend 

SI” in the “Progress Sonic ESB Developer's Guide”. 


Improvements for Responsive Business Integration: Sonic and Actional 

Improvements for Responsive Business Integration: 

Sonic and Actional 

Progress® Sonic® 8.5 introduces the following features to improve integration with 

Progress® Actional® 8.2.3: 

● “Actional Support for Sonic Connect” 

● “Actional SDK Version Upgrade” 

● “Configuring Actional Interceptors” 

● “Actional - Multi-part Message Payload Capture” 

Actional Support for Sonic Connect 

The Sonic Connect and Actional interceptors provide visibility into inbound and 

outbound RESTful and SOAP calls from the Sonic Connect stack: 

● Installed with Sonic ESB: 

■ Sonic Connect CXF Jetty Interceptor 

● Available from Progress Actional: 

■ Actional CXF Interceptor 

■ Actional Servlet Interceptor 

These interceptors enable you to instrument the SOAP and REST interactions of a 

Sonic Connect service. 

◆ To import the Actional Interceptors into the Directory Service: 

1. Connect to the domain manager and open the Sonic Management Console. 

2. Select the Configure tab, then in the left pane select the node Resources. 

3. Within Resources, create a folder named Actional, then a subfolder named 8.2.3. 

4. At that location, select Action > Import File to open the Select Import File dialog box. 

5. Browse to the location of the actional-cxf-interceptor.jar and actionalservlet-interceptor.jar 

files, select the files, and click Import. The jar files are 

imported to the Directory Services and are available for configuration. 

For more information, see the chapter “Using Actional with Sonic Components” in the 

“Progress Sonic ESB Configuration and Management Guide”. 



Actional SDK Version Upgrade 

Prior to Sonic 8.5 release, the Actional SDK was embedded in the MF container archive 

(MFcontainer.car). Sonic 8.5 release enables independent upgrade of the Actional SDK. 

To specify a preferred or upgraded Actional SDK, open a management container’s 

Resources tab, as shown: 

The Actional SDK Archive and the Actional Plug Maker Archive are described as 

follows: 

Property Description 

Actional SDK 

Archive 

Actional Plug 

Maker 

Archive 

Specifies the Progress Actional SDK archive file for this container. When 

an updated Actional SDK file is available, and you choose to locate in a 

different path or name, you can specify that this container use the updated 

Actional SDK file. 

Specifies the Progress Actional Plug Maker archive file for this container. 

When an updated Actional Plug Maker file is available, and you choose 

to locate in a different path or name, you can specify that this container 

use the updated Actional Plug Maker file. 

For more information, see Chapter 4 “Configuring Containers and Collections” of the 

Progress SonicMQ Configuration and Management Guide. 


Improvements for Responsive Business Integration: Sonic and Actional 

Configuring Actional Interceptors 

When using Progress Actional Management Server with Sonic ESB, you might need to 

add additional Actional interceptors to a Sonic container to improve its visibility. 

Common use cases for adding interceptors to a Sonic container are: 

● Using the Actional JDBC interceptor to instrument the database interactions of a 

Sonic Database service. 

● Using the Actional Servlet and CXF interceptors to instrument the SOAP and REST 

interactions of a Sonic Connect service. 

To set up the interceptor on the container, do the following: 

a. Import the interceptor JARs into sonicfs. 

b. On the container’s Resources tab, enter the classpath of each of the interceptor 

JARs. 

c. On the container’s Environment tab, set a com.actional.aops system property for 

each interceptor to enable it. 

Sonic automatically enables the Actional PlugMaker Java agent when the property has 

been set. 

For example, to enable the Actional JDBC interceptor: 

● Add the classpath of actional-jdbc-interceptor.jar as a prepended classpath. 

● Add the system property named com.actional.aops with the value 

com/actional/lg/interceptor/jdbc/jdbc.aop. 

Refer to Progress Actional’s Interceptor Guide for details about the com.actional.aops 

property. 

See the Progress Sonic ESB Configuration and Management Guide chapter “Using 

Actional with Sonic Components” for more information about Actional Servlet and CXF 

interceptors to instrument the SOAP and REST interactions of a Sonic Connect service. 



Actional - Multi-part Message Payload Capture 

This feature allows you to capture multiple message parts for audit/inspection by Actional 

so that the user can get visibility into their process behavior. 

To leverage Actional multipart support, Sonic 8.5 provides the Progress Actional 8.2.3 

SDK. Actional Management Servers and Agents must correspondingly be at 8.2.3 or 

higher. 

For more information, see “Impact of Multipart Message Capture on Legacy Behaviors” 

on page 64. 

The Payload Capture is also documented under “Managing Containers” in the “Tasks” 

section of the Getting Started with Progress Sonic Workbench online help. 


What’s Also New in Sonic ESB and Sonic Workbench 


The following features are also introduced in Sonic ESB and the Sonic Workbench in the 

8.5 release: 

● “Directory Service (DS) Connect for Eclipse” on page 31 

● “Message Mapping Enhancements” on page 34 

● “Reduce Contention in endpoint.call()” on page 43 

● “Per-Message URL Override for Sonic Connect” on page 43 

● “Domain View Integration” on page 44 

● “Scrollbar enhancements to Workbench Views” on page 46 

● “Restart & Reload Simplification” on page 46 

● “Lazy-Load Palette Categories” on page 46 

● “Report a Technical Issue” on page 46 

● “WS-I compliant WSDLs for Sonic Connect” on page 48 

● “SMC Performance in Large Domains” on page 49 

● “ESB support for global RME destination” on page 49 

● “Latest DataDirect Drivers” on page 49 

● “New ESB Service Metrics and Notifications” on page 49 

Directory Service (DS) Connect for Eclipse 

The Sonic DS Connect component is an independent feature and helps an Eclipse 

platform client such as DataXtend SI to: 

● Connect to a Sonic Directory Service and browse through Sonic ESB configurations 

● Provide contract details (if available) for a Sonic ESB configuration 

Using this component, you can use any other Progress product to achieve the same 

functionality. This also allows the multi-product developer to integrate with a Sonic 

endpoint with a reduced effort and time. 



The new DS connect component has introduced modification in the following existing 

interface: 

● Domain Connection — The Domain Connection dialog box is modified and has been 

divided into two sections: Domain Connection Details and Workbench Settings as 

shown in the following screen capture: 

This dialog box is documented under “Sonic Domain” in the “Sonic Workbench basics” 

section of the Getting Started with Progress Sonic Workbench online help. 

The DS Connect feature provides the following new interfaces: 

● Sonic Domain Connection 

● ESB Address Chooser 

Sonic Domain Connection 

This information is available in the online help. It is presented here as a documentation 

workaround for a defective link behavior observed in 64-bit Eclipse on 64-bit Linux. 

The Sonic Domain Connection dialog box opens when the system cannot establish a 

connection with the available domain connection details in the preference page before 

using the ESB Address Selection dialog for browsing the DS contents. After you provide 

correct connection details and press connect, the domain connection is established with 

the details given in the dialog box and updates the preference page with new connection 

details. 


◆ To connect to a Sonic domain: 


1. In the Domain Connection Details section, specify or modify the following settings: 


Domain Name Name of the domain that you want to connect. The default is 

2. Click Connect. 

ESB Address Chooser 

You can use the ESB Address chooser to select the available ESB configurations. You can 

select the ESB address from a list of existing addresses obtained from the Sonic Domain. 

You can use the following icons to show Endpoints, Services, and ESB processes. 

To select the ESB Address: 

1. In the Selection field, specify to filter the possible configurations. 

2. Click OK. 

Domain1 

Connection URL(s) URL(s) of the management broker(s). The default is 

tcp://hostname:2506. 

User Name The user name to connect to the domain manager. The default is 

Administrator. 

Password The password to connect to the domain manager. The default is 

Administrator. 

Icons Description 

Click the Show Endpoints icon to view the list of available endpoints. 

Click the Show Services icon to view the list of available services. 

Click the Show Processes icon to view the list of available processes. 



Message Mapping Enhancements 

The following changes are introduced in the Sonic Workbench message mapping page: 

● Incorporate Custom & Constant Expression Support in Expression & Mapping Rule 

Participants dialog box 

● Static set of root nodes replaced with Advanced node 

● Filter Transformation Actions as per source and target of Mapping Rule 

● Editable transformation action 

● Provision of double-click option to edit MappingRule 

● Availability of Tabular View in the message mapping page 

● Displaying validation markers in message mapping pages 

● Support EL Expressions for Runtime Parameters 

● File Resource mapping 



Custom and Constant expression support in Expression dialog box 

This feature enables the Sonic developer to define custom and constant expressions using 

the Expression dialog box. 

The following screen capture shows that when you select Custom from the Source Type 

list, an Expression box is displayed. In this Expression box, you can define your custom 

expression. 

The following screen capture shows that when you select Constant from the Source Type 

list, a Value box is displayed. In this Value box, you can define your constant value. 



Custom and Constant expression support in Mapping Rule Participants 

dialog box 

To create a new mapping rule the Sonic developer can directly pull a connection from a 

source node to a target node. If the source and target both are mappable, a mapping rule 

is created; otherwise, Mapping Rule Participants dialog is launched seeking user input. 

In the previous release, there was no support for Constant Value and Custom 

Expressions in the Mapping Rule Participants dialog. You had to first add each mappable 

individually and then pull connections directly between mappables. The Sonic 8.5 release 

now enables the Sonic developer to define custom and constant expressions using the 

Mapping Rule Participants dialog box. 



Static set of root nodes replaced with Advanced node 

In the previous Sonic release, following static components were present in the source and 

destination map: 

● Constant 

● Property 

● System 

● Container 

● Custom 

All these components are now merged into one and is called Advanced node. 

Filter Transformation Actions as per source and target of Mapping Rule 

In prior releases of Sonic, in message mapping pages, all the transformation actions 

supported by runtime were made available to you for any given MappingRule. You had to 

correctly set the right transformation action considering the source and target involved. In 

the current release of Sonic, tools make only those transformation actions available which 

are valid for the given context, that is, mapping rule source and target. This filtering is 

done, considering MappingRule source type and target type, and type supported by a 

given transformation action. 

For more information, see Chapter 3 “Tasks” in the “Progress Sonic ESB Developer's 

Tools Guide”. 

Editable transformation action 

MappingRule transformation action details are persisted as two attributes: action and use. 

For example: . 

To support advanced users, tools provide editable transformation action combo. This 

enables you to type the action string which display another text box seeking action details. 

Values entered by the user is persisted to .esbp as it is. 



Provision of double-click option to edit Mapping Rule 

This feature enables you to edit Mapping Rule by double-clicking the connection map 

available between source and destination. For example, if you double-click a connection 

and then click the 'Edit Mapping Rule' action, the Mapping Rule Participants dialog box 

open in editable format. 

Availability of Tabular View in the message mapping page 

The tabular view provides a snapshot of all the mapping rules defined for a step. To see 

the transformation and target action details of a mapping rule in the graphical view, you 

have to select the rule and then view the details in the lower half of the mapping page. 

However, in the tabular view, a complete snapshot of the mapping rule, including 

transformation action and target action, is provided. 

The following screen capture displays a tabular view in the message mapping page: 



Displaying validation markers in message mapping pages 

Errors encountered on validating an ESB process are displayed in the ESB editor root 

page. Validation markers are set on the resource for each invalid mapping rule. When you 

move the mouse pointer over the validation marker, the error is displayed, as shown in the 

following image: 

For more information, see Chapter 3 “Tasks” in the “Progress Sonic ESB Developer's 

Tools Guide”. 

Support EL Expressions for Runtime Parameters 

Sonic 8.5 release provides support for runtime parameters at message mapping level in 

addition to defining process context properties in the request/ response/ fault mapping 

pages. 

Prior to Sonic 8.5 release, you had to set runtime parameter value in the Service page or 

you had to map the parameter to incoming XQMessage by clicking the checkbox in runtime 

parameters table. Limitation to this approach was that you cannot add any new parameter 

and you had to use the existing parameters defined at service type level. 



In the message mapping user interface, a Step Context node is added when you right-click 

the Advanced node on both the Source and Destination sides. You can now define new 

runtime parameters under the node as shown in the following screen capture: 

When you right-click the Step Context node and then click Add New. The Expression 

dialog box opens. 

Note that the Step Context Parameter box is populated with the service runtime 

parameters and is editable. You can type any parameter if required and this parameter is 

added to runtime parameters and is specific to the step. 



If you provide mapping between the Step Context nodes of Source and Destination, the 

following Mapping Rule Participants dialog box opens: 

File Resource mapping 

Sonic Workbench 8.5 release enables you to define a mapping rule using a file as a source. 

You can specify a file as a source by using the Expression dialog box or the Mapping Rule 

Participants dialog box. You must provide the following properties: 

File URL: You can select a file from the Sonic file system or the local file system. You can 

also create a new file and specify it as a mapping source. 

Dynamic: After you specify a file name in the File URL field, you can check the field to 

make the ESB process read the file from the disk instead of the cache memory. By default, 

the file is read from the cache memory. 



When you right-click the Advanced node and select Add New, the Expression dialog box 

opens. You can select File Resource from the Source Type drop-down box and specify the 

required properties. 

When you create a mapping rule using the Mapping Rule Participants dialog box, select 

File Resource from the Source Type drop-down box and specify the required properties. 


Reduce Contention in endpoint.call() 


The XQEndpoint.call() operation allows a custom Java service to programmatically 

invoke an ESB endpoint. 

During calls to the XQEndpoint.call API, ESB sets the ReplyTo destination in the 

message from a fixed pool of temporary destinations. After the API call returns, the 

temporary destination is returned to the pool and re-used for subsequent API calls. In 

events where the API calls exceed the timeout interval, the temporary destinations are 

returned to the pool. If a response arrives for the timed out request, then it might be 

incorrectly treated as the response for a subsequent request. 

To resolve this issue, you can use one of the following methods: 

● Set the SonicESB.RefreshDestinationsOnCall system property to true. When you set 

this property, a unique temporary destination is used for each call. This can lead to a 

large number of temporary destinations if a large number of concurrent 

Endpoint.call API calls are expected. 

● Set the SonicESB.UniqueJMSCorrelationIDOnCall system property to true. When you 

set this property, each message is assigned a unique JMSCorrelationID before the 

Endpoint.call API call. 

This information has been added to the Sonic Workbench online help in the Workbench 

and in its PDF version, Sonic ESB Development Tools guide. 

Per-Message URL Override for Sonic Connect 

Sonic Connect Service allows you to override the destination URL of a web service 

invocation step using a request mapping rule. 





Domain View Integration 

The Project Explorer in Sonic Workbench has been refurbished and it now enables you to: 

● View ESB Configurations 

● Drag and drop support for ESB Address nodes 

● Quick way to create ESB Process from the Project Explorer 

View ESB Configurations 

In Sonic 8.5 release, the ESB configurations such as, Endpoints, Services, and Processes 

are placed under the Domain1 node of Project Explorer. This helps you to view the 

complete projects and DS configurations as shown below: 

Drag-and-drop support for ESB Address nodes 

This feature enables you to drag the ESB address onto editors at relevant target locations, 

such as ESB process editor, Message sender view, Message listener view and so on. This 

reduces your effort to locate and choose address and thus enhances the usability. 



In Sonic 8.5 release, it is now possible to drag and drop Directory Service Address nodes 

on ESBP Entry, Exit, Fault and RME endpoint node. For example, you can drag and drop 

an Entry endpoint from the Project Explorer to the ESBP editor 

. 

You can also drag and drop an ESB Address on Process flow to create an appropriate step. 

The dropped address will get set as the Service/Endpoint/Process for the step. For 

example, in the following screen capture, a service is dragged and dropped to an existing 

ESB process to create a step. 

Quick way to create ESB Process from the Project Explorer 

You can create ESB Processes from Project Explorer by clicking the context menu of the 

service operations available in domain node and able to run it. 

For more information, see Chapter 10 “Getting started with Sonic ESB and DataXtend 

SI” in the “Progress Sonic ESB Developer's Guide”. 



Scrollbar enhancements to Workbench Views 

Sonic Workbench views have been enhanced to provide scroll bars. This feature allows 

the user to see and input to various controls which are inaccessible on lower resolution 

displays. For example, the ESB process Overview page contains a lot of information 

which can now be visualized in many common resolutions. 

Restart & Reload Simplification 

After uploading or removing a service, Sonic Workbench prompts you to either restart or 

reload a container based on the current state of the ESB container. If the container is 

already in start mode, the Workbench monitors the services deployed on the ESB 

container. Sonic Workbench decides and prompts you to restart or reload the container 

based on the nature of the deployed services. For example, the container will be restarted 

if a Sonic Connect service or a BPEL service is uploaded or already deployed on it. If the 

container is shutdown, Sonic Workbench prompts you to start it. 



Lazy-Load Palette Categories 

Prior to Sonic Workbench 8.5, the Sonic Workbench took a long time to load items in the 

palette because they are fetched from the Directory Service. However, many items remain 

unused and can be loaded in the background, or when their palette category is expanded. 

Report a Technical Issue 

Report a Technical Issue is an Eclipse based plug-in to report bugs or enhancements in the 

product by customers. This feature allows you to attach container logs to the bug report 

and share the issue with the technical support team at Progress for resolution. The bug 

report information is shared as an XML file which is useful in passing the required 



information programmatically and resolving the issue. With this feature, you can also 

attach files such as error screen captures or network usage. 

You can report a technical issue through the Console view displaying container logs, by 

right-clicking the relevant entry in the Error Log and selecting Report Technical Issue, 

through the Project Explorer view, and by selecting Help > Report Technical Issue. 

This information has been added to the Sonic Workbench online help under the Progress 

Technical Issue Reporting Guide section. 



WS-I compliant WSDLs for Sonic Connect 

Sonic Workbench 8.5 introduces improved Web Service wizards which allow the users to 

generate WS-I compliant WSDLs while exposing ESB Processes as Web Services. 

A new group, Binding Options, is added which allows the user to select the binding style 

to be used while generating a WSDL file. The options are: Document literal, Document 

literal with Wrapped style, and RPC literal. 




SMC Performance in Large Domains 


The throughput time of SMC is improved when searching for data from the Directory 

Service in large domain. All the request and response actions are compressed thereby 

saving time to load the artifacts from DS. 

Select the Enable Compression checkbox to compress all the request and response 

actions thereby saving time to load the artifacts from DS. 

ESB support for global RME destination 

If the RME destination cannot be determined, the errors are sent to a global RME 

destination. 

Latest DataDirect Drivers 

Sonic Workbench 8.5 ships with the latest DataDirect drivers. 

New ESB Service Metrics and Notifications 

Sonic ESB extends its metrics and notifications beyond esb.service.messages.* metrics, 

application.service.* notifications, and system.state.* notifications. The following 

ESB metrics and notifications are introduced in Sonic 8.5. 

esb.connect.requests Metrics 

As these are metrics specific to Sonic Connect services, they are settable on the SMC’s 

Configure tab, but will be available on the Runtime tab only if the ESB Container contains 

a Sonic Connect service. 



The esb.connect.requests.* metrics include: 

● Average Processing Time 

● Faulted 

● Received 

● ReceivedPerHour 

● ReceivedPerMinute 

● ReceivedPerSecond 

FileDrop and FilePickup Metrics 

As these are metrics specific to Sonic File services, they are settable on the SMC’s 

Configure tab, but will be available on the Runtime tab only if the ESB Container contains 

Sonic File services 

● The FileDrop.* metrics include FailedFileDropCount and FileDropCount 

● The FileDrop.* metrics include FailedFilePickupCount and FilePickupCount 

application.alert.esb.service.messages.* Alert Notifications 

An ESB Container can be set to report alert notifications by ESB Container, management 

container, or domain for threshold crossings on: 

● AverageProcessingTime 

● ReceivedPerHour 

● ReceivedPerMinute 

● ReceivedPerSecond 

For more information, see the “ESB Containers” chapter of the Progress Sonic ESB 

Configuration and Management Guide. 

What’s New in SonicMQ and Management Framework 

The following features are introduced in SonicMQ in 8.5: 

● “Routing Connection (DRA) Flow Control Notifications” on page 51 

● “Alert Notification Repeats When Still Over a Threshold” on page 54 

● “Browse-only ACL” on page 54 

● “Improved CAA Failure Detection” on page 55 

● “Minimize Subscriber Traffic” on page 56 



● “Added functionality in C and C++ Clients” on page 57 

● “Container log records CPU/Core Count, and ProcessID” on page 58 

● “Advanced Broker Property To Check for Oversized Messages” on page 58 

● “Administered Objects Tool Enables Use of Sub-contexts” on page 58 

● “Enhanced Documentation: Quality of Protection settings” on page 59 

● “Enhanced Documentation: Running Sonic as a Linux service” on page 59 

● “Cluster-level Flow-to-disk Parameter” on page 60 

● “Named Sessions” on page 60 

Routing Connection (DRA) Flow Control Notifications 

A routing connection provides a way for an application to dynamically route a message 

through a connected broker to a destination on another broker. As the brokers involved in 

a DRA routing connection could be in different management domains, the point of view 

of an administrator in one of those domains will be constrained. 

Flow control notifications for dynamic routing are similar in concept to cluster flow 

control notifications. The outgoing side of the routing connection is monitored once per 

configured interval to check whether it is flow controlled. A connection is flow-controlled 

if it has messages to send, but is unable to send them because it has received a directive 

from its peer to limit sending. It can only send messages higher than a certain priority 

(Pub/Sub flow control) or messages that are not for blocked destinations (PTP flow 

control). If the connection has been flow-controlled for a whole monitor interval, a flow 

control ‘pause’ notification will be sent. Notifications will be sent once per monitor 

interval as long as the connection remains flow controlled. 

A resume notification is sent when the connection receives a directive to resume sending. 

While the ‘pause’ notification combines pubsub and ptp data into a single notification, 

resume notifications are sent when the individual resume event occurs. 

To provide the data for a notification, the sending connection identifies that it is flow 

controlled and the receiving broker supplies the details about blocking resources. The 

receiving broker sends the notification. When brokers are in the same management 

domain, the notifications are visible to administrators of both brokers. 

However, for routing connections, sending broker and the receiving broker are often in 

different management domains. A notification produced by the receiving broker’s domain 

may not be visible in the sending broker’s domain. Furthermore, data from the receiving 

broker about blocking resources (subscribers) is not meaningful in the sending broker’s 

domain, and exposing the information would present a security violation. Even without 



all the data about the source of flow control, a sender-side notification can be useful in 

alerting an administrator to problems with the routing connection. 

For this reason, DRA flow control notifications are produced on both the sending and the 

receiving brokers. Notifications generated on a sender side will have a different 

notification name than notifications generated on the receiver size. Users can select which 

notifications to subscribe to depending on their environment. The sender side 

notifications will not contain details of blocking subscribers, but will indicate the 

blocking type (pubsub or ptp) and blocking priority. 

Pause Notifications on Routing Connections 

Pause notification indicates that a DRA routing connection is unable to send messages. 

To produce the pause notifications, the sending side of each DRA connection is checked 

once per monitor interval to determine whether it is flow-controlled. If the connection has 

been flow controlled for a full interval, the routing connection. 

Pause notifications are produced once per monitor interval for as long as the connection 

remains flow-controlled. 

Resume Notifications on RoutingConnections 

Resume notifications are sent when sending on the DRA connection has resumed. 

Sending can resume when a queue destination is no longer blocked, or the minimum 

priority of messages that can be sent has been adjusted downwards. There can be multiple 

resume notifications following a pause notification. 

A ResumeType of "PUBSUB" indicates that sending has resumed for pubsub. This means that 

all the subscribers listed in the previous ClusterConnectionPause notification have 

allowed the Connection to resume sending. 

A ResumeType of "PTP" indicates that sending has resumed for the named destination. 

There is one resume notification per resumed destination. 

For the complete information, see the “Managing SonicMQ Brokers” chapters of the 

Progress SonicMQ Configuration and Management Guide. 

Sample Application 

A sample application was added to SonicMQ Management samples, 

BrokerFlowControlNotificationReporter.java. It creates a notification listener that uses 

a notification filter to receive only flow control notifications for clustered and routing 

connections. To see the notifications, you need a scenario that induces flow control. See 



the sample’s readme file and refer to the Progress SonicMQ Administrative Programming 

Guide for more about runtime management applications. 



Alert Notification Repeats When Still Over a Threshold 

Alerts enable you to set a series of thresholds that produce a notification when each 

threshold is crossed. In prior releases, the notification was sent just at the point when the 

threshold was crossed. In Sonic 8.5, you can choose to have alert notifications sent again 

at the collection interval if the current value is still over the threshold. 

The initial alert describes the date/time at the notification source that the threshold was 

initially crossed. If there are multiple thresholds defined for a given metric, the date/time 

will be updated to reflect the most recent threshold that was crossed; however, if no 

additional threshold is crossed, a repeat metric alert notification will contain the same 

date/time as previously sent. 

Each repeat alert indicates whether the metric alert notification is a repeat of a previously 

sent metric alert notification. If there are multiple thresholds defined for a given metric, 

the attribute value will reflect whether the alert is the first alert (where value = false) that 

is being sent regarding a particular threshold having been crossed. 

On the Metrics tab of each component type that supports metrics, the following 

information describes its Repeat Alert Notifications option: 

When selected, causes an alert notification to be repeated at the refresh interval if the 

threshold is still crossed. The default value is cleared (notifications are sent only at 

the crossing of a threshold.) 

This material was added to the Progress SonicMQ Configuration and Management Guide. 

Browse-only ACL 

A new action was added to Authorization Policy Access Control List definitions, enabling 

a user or group to be granted permission to see messages in a queue, but denied 

permission to consume messages from the queue. 

Browsing is implicitly allowed for any user granted receive permission. Browse 

permission where receive permission is denied, allows messages to be only viewed, an 

appropriate control for many clerical and auditor functions. 

If you choose to implement Receive access control to the dead message queue (DMQ), 

you might want to DENY Receive access to the common group PUBLIC and then: 

● GRANT Receive access to groups and users allowed to consume from the DMQ 

● GRANT Browse access to groups and users allowed to review yet not consume from the 

DMQ 



See the chapter “Security Considerations in System Design” in the Progress SonicMQ 

Deployment Guide, and the chapter “Configuring Security” in the Progress SonicMQ 

Configuration and Management Guide for more information. 

Improved CAA Failure Detection 

Connections to Sonic brokers can fail for a number of reasons (processes die, machines 

fail, network hardware fails, wires get cut, etc.). Many failures do not result in immediate 

TCP layer identification and reporting of the failure, and thus a Sonic broker could be 

unaware of failure through a delay that goes beyond intended service levels. 

New connection failure settings provide: 

● A consistent connect & connection failure detection mechanism across cluster and 

replication broker-to-broker connections 

● A consistent set of configurability and configuration settings for the connection 

failure detection across such connections 

● A common look & feel to the UI used to configure the settings 

This new connection failure detection mechanism may be used: 

● As a supplement to OS TCP connection-failure detection mechanisms 

● Effectively as a replacement for OS TCP connection-failure detection mechanisms 

(which may be desirable since changes to OS TCP settings will affect all applications 

running on the same host) 

● As a means to achieve reduced connection failure detection times for platforms that 

do not support configuration of TCP settings for early connection-failure detection 

For complete information, see the “Tuning TCP to Optimize CAA Failover” chapter of 

the Progress SonicMQ Performance Tuning Guide. 

Enhanced Documentation: Tutorial on Using SSL 

Using SSL requires setting up appropriate PKCS12 and JKS keystore resources on clients 

and brokers, and establishing appropriate credentials and certificates. Two step-by-step 

tasks detail setting up SSL to use client authentication and setting up not using client 

authentication. The client aspects are described for both the standard Java client, and 

.NET guide. 

See the chapter “Tutorial on Using SSL in Sonic” in the Progress SonicMQ Deployment 

Guide. 



Minimize Subscriber Traffic 

The feature lets an application effectively shut down or reduce the subscriber’s client 

buffer to minimize the background priming (at the cost of increased latency). 

When set to true, the subscriber will attempt to flow control the broker as soon as 

messages are delivered into the client’s buffer. The subscriber could receive more 

messages put on the wire by the broker before it receives the flow control message. 

Sending resumes when the subscriber's buffer becomes empty. 

The setting to minimize subscriber traffic is implemented on the Java, C, and C++ clients, 

as follows. 

Java Client 

The setMinimizeSubscriberTraffic method in 

progress.message.jclient.ConnectionFactory provides control over TopicSubscribers 

and DurableSubscribers. The following syntax sets the option to minimize subscriber 

traffic: 

ConnectionFactory.setMinimizeSubscriberTraffic(boolean value) 

where: 

■ value is true when you want to minimize subscriber traffic 

A related method is public java.lang.boolean getMinimizeSubscriberTraffic(). 

It returns the value that indicates whether subscriber traffic is being minimized. 

See the chapter “SonicMQ Connections” in the Progress SonicMQ Application 

Programming Guide for more information. This option can be set on Connection 

Factories that are defined as Administered Objects. See the Progress SonicMQ 


C Client 

In C client, 

int TopicConnectionFactory_setMinimizeSubscriberTraffic 

(HOBJ thisObj, jboolean minimizeTraffic); 

See the Progress SonicMQ C Client Guide for more information. 

C++ Client 

In progress::message::jclient::TopicConnectionFactory: 

void setMinimizeSubscriberTraffic(jboolean minimizeTraffic); 

See the Progress SonicMQ C++ Client Guide for more information. 


Added functionality in C and C++ Clients 


In addition to the ability to minimize subscriber traffic, the C and C++ clients now provide 

the following functionality enhancements: 

Login SPI 

The SonicMQ C client and C++ Service Provider Interfaces (SPI) are used on the client 

side to authenticate JMS client applications where the broker is using Sonic’s external 

security implementation, Pluggable Authentication and Security Service (PASS). 

Implementation of this interface requires implementing the Authentication SPI and the 

Management SPI on the broker side. 

The Authentication SPI is used to authenticate JMS clients connecting to a broker via the 

delegation mode, and to perform callback operations on the broker. The Management SPI 

is used by the Sonic Directory Service to replicate users and credentials into the Sonic 

Directory Service. This information is used in the Sonic Management Console to provide 

a graphical read-only representation of users and groups in the external domain. 

See the chapter “Using Login SPI for Sonic Authentication” in Progress SonicMQ C 

Client Guide and Progress SonicMQ C++ Client Guide for more information. 

SSL Support 

SonicMQ supports encryption at the connection level through SSL. This material 

describes the programming concepts and actions required to establish and maintain 

connections to SonicMQ brokers through SSL in the SonicMQ C and C++ clients. 

SonicMQ C and C++ clients use the OpenSSL library included in the client package. You 

set runtime properties to identify the certificates, and the cipher suites preferred for the 

encryption of the communication channel. The default cipher suite is RC4-SHA:RC4-MD5. 

These properties can be established in any one of the following ways: 

● Command line — Pass the SSL properties at the command line when starting the 

application. 

● Programmatically — Set the SSL properties in your application. 

For optimal security, consider using LoginSPI in conjunction with SSL so that the 

obfuscated credentials are encrypted at the connection level. 

See the chapter “SSL Connections” in Progress SonicMQ C Client Guide and Progress 

SonicMQ C++ Client Guide for more information. 



Container log records CPU/Core Count, and ProcessID 

Every container log records additional platform information that enumerates the available 

processors, and identifies the container’s JVM’s process, as shown: 

Sonic Management 

Release 8.5.0 Build Number nnn 

Copyright (c) 1999-2011 Progress Software Corporation. 

All rights reserved. 

Local host: machineone (Windows XP - 5.1) 

Available Processors: 2 

Java Process ID: 5512@machineone 

Java(TM) SE Runtime Environment (build 1.6.0_11-b03) 

Sun Microsystems Inc. (home C:\Program Files\Progress\Sonic\MQ8.5\jre, 

version 1.6.0_11) 

Java HotSpot(TM) Client VM (build 11.0-b16, mixed mode) 

Configured Arguments : -Xms64m -Xmx512m 

Configured Properties: 

Advanced Broker Property To Check for Oversized Messages 

A new advanced broker property enables a broker to return an exception to a JMS 

publisher when the publisher's message causes TopicDbSize to be exceeded. Set 

BROKER_PUBSUB_PARAMETERS.CHECK_DB_SIZE_ON_PUBLISH to true to enable the feature. 

Administered Objects Tool Enables Use of Sub-contexts 

The initial context in a JNDI store can result in a large flat file structure. You can add subcontexts 

to distinguish categories and subcategories of administered objects. 

The Sonic Deployment Manager provides a way to import and delete JNDI entries and 

sub-contexts that are easy to maintain and extend. See the SDM sample model JNDI for 

details. 

◆ To add a sub-context to the internal JNDI store: 

1. Create a connection to an internal object store. 

2. Right click on the connection you want to extend with sub-contexts, and then choose 

Create Sub-Context. 

3. In the Create Sub-Context dialog box, enter the name you want to use. 



4. Right-click on a sub-context name to create subordinate levels. 

5. Click on a store name or subcontext name, and then enter destinations and connection 

factories that can be referenced by their sub-context. The following figure shows three 

connection factory objects: 

These ConnectionFactories were created by the Sonic Deployment Manager’s 

JNDI/Import sample, and are located in the JNDI store at a subcontext of jms.sonic. 

Enhanced Documentation: Quality of Protection settings 

The documentation for Quality of Protection (QoP) equated its evaluation to Access 

Control Lists. While the inheritance model and the use of template characters in QoP 

settings is similar to ACLs, the value of the QoP setting determines whether the setting 

can be changed at a lower level of the hierarchy or overridden by an application. When 

integrity is set at a hierarchical level, only settings to privacy or application overrides 

(to privacy) below that level are honored, and you cannot change any lower level to none. 

See the revised documentation in the “Quality of Protection” section of the chapter 

“Security Considerations in System Design” in Progress SonicMQ Deployment Guide. 

Enhanced Documentation: Running Sonic as a Linux service 

While Sonic provides no helpers for creating a service in Linux, a Linux developer 

provided a pattern that he uses to start and stop Sonic containers on a Linux machine. 

See the note at the end of the chapter “Setting Up Containers” in the Progress Sonic 

Installation and Upgrade Guide for a complete listing of this script. 



Cluster-level Flow-to-disk Parameter 

A cluster parameter to configure the flow-to-disk setting has been added. The setting will 

apply to all brokers in a cluster. The default value is false. The parameter works in the 

same way as other cluster-level parameters such as RoutingNodeName and 

FlowControlMonitorInterval: when a broker is a member of the cluster, the cluster-level 

parameter applies and the broker-level setting is ignored. 

See 

Note Impact when upgrading — When an Sonic installation is upgraded, the Domain 

Manager upgrade will set the cluster-level flow-to-disk parameter to true if any 

broker in the cluster has flow-to-disk enabled 

For more information, see the “Configuring SonicMQ Brokers” chapter of Progress 

SonicMQ Configuration and Management Guide, and the “Flow to Disk Publishing” 

chapter in the Progress SonicMQ Performance Tuning Guide. 

Named Sessions 

Additional createSession() methods allow you to add a session name that will be 

exposed in session information, as in the Manage > Broker > Connections panel in the 

Sonic Management Console. 

The signature of this createSession() method is as follows: 

progress.message.jclient.Connection.createSession 

(boolean transacted, int acknowledgeMode, String sessionName) 

where sessionName is a String that is a set of characters, a null, or an empty String, in 

which case, the behavior is the same as the standard API without sessionName. 

Get session’s name with String progress.message.jclient.Session.getSessionName() 

Corresponding TopicSession, QueueSession, and XA methods that enable named sessions 

are defined in the API. 

This information was added to the Progress SonicMQ Application Programming Guide. 


Viewing Session Names 


When a JMS client has provided a name for a session, the session name becomes part of 

the application identifier. Then, connections can display the name of each session to make 

it easier to navigate to the associated consumers, as shown: 

See the “Managing SonicMQ Broker Activities” chapter of the Progress SonicMQ 

Configuration and Management Guide for more information about viewing connection 

and session details. 



What’s New in Sonic Deployment Manager 

The Sonic Deployment Manager added one SDM-specific feature as well as elements that 

enable the configuration of features in the Sonic 8.5 release: 

Element to Specify Shutdown After Run 

In the Model.xml file, the following element was added to specify that when a run 

completes, the Domain Manager container shuts down: 

● DSHost 

■ ShutdownAfterRun 

Elements for Setting Failover Properties 

In the Tuning schema, the following elements adjust failover properties: 

● ClusterParameters 

■ ConnectTimeout 

■ PingInterval 

■ PingTimeout 

● Replication 

■ ConnectTimeout 

■ PingInterval 

■ PingTimeout 

Element for Browse ACLs 

In the Model schema, the following element was added: 

● ACL : AclType 

■ BROWSE_ACL 

Element for Notification Alert Repeats 

In the Tuning schema, the following element was added: 

● Metrics 

■ RepeatAlertNotifications 


Elements for Actional SDK Archive and Plugmaker 

In the Tuning schema, the following elements were added: 

● ContainerResources 

■ ActionalSDKArchiveName 

■ ActionalPlugmakerArchiveName 

Element for Cluster/DRA Flow Control Notifications 



■ FlowControlMonitorInterval 

● RoutingParameters 

■ FlowControlMonitorInterval 

Elements for Cluster Flow to Disk 



■ FlowToDisk 

What’s New in Sonic Deployment Manager 

Note Migrate SDM Models to 8.5 — It is a good practice to run migrateModel against any 

existing models you want to use in a Sonic 8.5 deployment as the model will be 

updated so that its elements correspond to the 8.5 SDM schema. 



What’s Changed in Sonic 8.5 

Some changes in Sonic 8.5 have an impact on existing deployments: 

● “Change in Default Windows Services behaviors” on page 64 

● “Impact of Multipart Message Capture on Legacy Behaviors” on page 64 

● “Cluster Flow To Disk parameter is Assumed by Members” on page 65 

● “Integrating with Eclipse Variables View” on page 65 

● “XML Tools” on page 66 

● “Improved Error Reporting” on page 66 

● “Sonic 8.5 and RSA” on page 67 

Change in Default Windows Services behaviors 

Window services now consider an initial attempt to connect to the Domain Manager as a 

completed startup, and thus the Windows service does not timeout waiting to connect. The 

connection timeout in attempting connect defaults to unlimited. These two changes 

provide improved standby behavior in deployed assets, particularly those that are awaiting 

a Sonic Deployment Manager run to provision the remote machines. 

Impact of Multipart Message Capture on Legacy Behaviors 

Sonic ESB now takes advantage of new Actional 8.2.3 SDK features to report multi-part 

payloads. When the ESB container option Enable Payload Capture is selected, and 

Actional policy is configured to require payload to be reported for an interaction, all ESB 

message parts are reported to Actional. 

This differs from the previous behavior of reporting only the first part of the ESB message 

where the part content-type was “application/xml”, “text/xml”, or listed in an advanced 

configuration property(payloadCaptureMimeTypes). 

Sonic ESB takes advantage of new Actional 8.2.3 SDK capabilities that allows 

determination of whether payload is required by the Actional Management Server (AMS) 

for either policy evaluation or for auditing purposes. ESB only incurs payload preparation 

and transmission overhead if absolutely required by AMS. 

Sonic ESB now reports payload size to AMS for ALL interactions independent of the 

Enable Payload Capture setting. To be consistent with other Actional interceptors, 

payload size is now reported as a representation of the bandwidth used for the 



communication. For intra-container or in-memory interactions a zero length payload size 

is reported. For interactions across JMS, JMS network bandwidth size is reported. 

This new payload size reporting strategy differs from the old behavior. Previously, 

payload size was reported only if Enable Payload Capture was set, and if reflected payload 

bytes reported to Actional (which was no more than the size of a single part). 

Should you need to revert to the previous payload and size reporting behaviors, an 

advanced configuration property can be set: LegacyPayloadReportingModeEnabled. 

There are two ways to apply this setting: 

1. On a specific container, set a Java System Property on the Resources tab of the 

management container, then add the name 

actional.interceptor.LegacyPayloadReportingModeEnabled and the value true, and 

then move the setting up to highest precedence. 

2. Domain-wide for all containers as a XQGlobalConfig property, connect to the domain 

with the esbAdmin tool, and then enter: 

set LegacyPayloadReportingModeEnabled true 

Cluster Flow To Disk parameter is Assumed by Members 

The setting for Flow To Disk is now provided as a cluster setting. The cluster setting 

overrides that setting on any member of the cluster. 

In Sonic Deployment Manager, the Flow To Disk setting is now in a cluster parameter set 

in the Tuning.xml. As you might be have other clusters that previously did not intend to 

use Flow To Disk, the parameter set by an upgrade of another cluster where at least one 

member had Flow To Disk set will force that seting on those clusters too. 

Integrating with Eclipse Variables View 

The Variables view shows the variables and messages at the current selection in the Debug 

view, unlike the Output view, which only shows the variables and messages at the end of 

running or debugging a scenario. Sonic Workbench contributes to the standard Eclipse 

Variables view. 



XML Tools 

Sonic 8.5 release introduces the following modifications in the XML Tools: 

● Sonic XSD and WSDL editor are deprecated in 8.5 and WTP WSDL and XSD editor 

are made as primary editor, because of following reasons: 

■ WTP XSD editor has more features as compared to Sonic XSD. 

■ To get SOAP 1.2 MTOM support from WTP WSDL Editor for Sonic Connect. 

● Sonic Workbench contributed to WTP editors to provide ESB Binding support for 

WTP WSDL editor. 

● The Sonic Design Perspective allows selecting File> New> WSDL, but the WTP 

WSDL editor is used. 

■ This will be effective in the following scenarios: 

❑ While opening file created using WTP wizard 

❑ While opening file created from imported project 

❑ While opening file created using Sonic XML Editor(s) wizard 

■ To open file with Sonic XML Tools, user must set the preference in the File 

Associations preference page by making Sonic Content type as Default one. 

Improved Error Reporting 

Sonic 8.5 release provides better user experience while running ESB Processes from 

Workbench. The goal is to report the ESB Services that are not deployed yet or that are 

not initialized properly which are part of ESB Process definition. 

Prior to Sonic 8.5 release, there was no mechanism to verify whether a service was 

deployed and properly running. 

In Sonic 8.5 release, Sonic Workbench collects all the ESB Services used in the ESB 

Process when an ESB process is run and checks if they are deployed in any of the 

managed containers. It also checks whether the service is started. 


Sonic 8.5 and RSA 


RSA libraries are not shipped with Sonic 8.0 or Sonic 8.5. This will not cause any impact 

for most users as SSL functionality is provided via Java Secure Socket Extension (JSSE). 

Only Certificate Revocation List (CRL) support requires RSA libraries. Customers who 

want to use this feature with Sonic 8.5 must purchase RSA libraries directly from RSA. 

The SSL configuration dialog contains a button Certificate Chain & CA Directory. SSL 

acceptors can be configured using PKCS7 or PKCS8 on the Edit Certificate Chain & CA 

Directory Properties dialog box. If they are configured instead of a JSSE keystore (as in 

the case of upgrade), PKCS7 or PKCS8 is used to populate a JKS keystore at runtime. 




Chapter 3 What was new and changed in prior 

Version 8 releases 

This chapter describes functionality in the Progress Sonic products in release 8.0 and 8.0 

SP 1 in the following sections: 

● “Sonic Installer and Launcher features in 8.0.x” on page 70 

● “SonicMQ and Management Framework features in 8.0.x” on page 79 

● “Sonic ESB and Workbench features in 8.0.x” on page 100 

● “Sonic Deployment Manager features in 8.0.x” on page 121 

This chapter describes Sonic functionality in Version 8 deployments. 

If you are advancing from Version 7, and your installations are not at the last Version 7 

release, 7.6 SP 2, review “What was new and changed in 7.5 and 7.6 releases” on page 129 

to see the changes in that were implemented in newer Version 7 releases. 

The required upgrade procedures for Sonic installations to advance from Version 7 

directly to Sonic 8.5 are detailed in “Upgrading from Version 7 to Sonic 8.5” on page 95. 

Return to this chapter to review the functionality introduced in 8.0. Then, “What’s new 

and changed in Sonic 8.5” on page 19 describes the latest functionality changes. 


Chapter 3: What was new and changed in prior Version 8 releases 

Sonic Installer and Launcher features in 8.0.x 

The following sections describe the Sonic Installer and the Sonic Container Launcher: 

● “New Installer Features” on page 70 

● “How Centralized Installation Works” on page 73 

New Installer Features 

Progress Sonic 8.0 introduced centralized installation, a new paradigm in installation, 

deployment, and launching of managed containers—changing from prior versions in 

fundamental ways. The features are summarized in the following topics: 

● “Overview of Centralized Installation” on page 70 

● “Introducing the Host Manager” on page 71 

● “Introducing the Container Launcher Installer” on page 72 

● “Applying Updates and Patches” on page 78 

Note See a demonstration of centralized installation and provisioning — A set of video 

presentations, How SDM Models Configure Remote Machines for Provisioning, details 

how an installed Domain Manager and three remote Launcher installations are 

provisioned through the Sonic Deployment Manager’s HotHotMessagingCluster model to 

establish replicated brokers on two of the machines. 

Overview of Centralized Installation 

Sonic now offers centralized installation and associated features that greatly simplify the 

configuration and management of distributed deployments. 

Centralized installation replaces a set of administrative tasks scattered across the 

domain’s topology with a simple install on each distributed system, and configuration 

functions that enable remote administrators to provision distributed systems with their 

required resources. Consider how key installation and setup functions have changed: 

Function Before centralized installation With centralized installation 

Domain Manager 

Setup 

Administration 

Tools Setup 

Required a sequence of installations 

on the Domain Manager system. 

Required a sequence of installations 

on each administrator’s system. 

All licensed products are installed in one 

process. 

All products are installed in one process with 

no license keys needed. 

Client Setup Required a license key. No license key needed. 



Function Before centralized installation With centralized installation 

Distributed 

Components 

Required a sequence of appropriate 

installations and license keys on each 

system. 

Activation Daemons Required a manual configuration task 

on remote system. 

Windows Services Required a manual configuration task 

on remote system. 

Initial Container 

Startup 

Data Isolation and 

Backup 

Sonic Deployment 

Manager 

Introducing the Host Manager 

Generic minimal installation creates a 

container that connects to the domain. 

No license key needed. 

Optional during initial container creation. 

Optional during initial container creation. 

Manual commandline action. Optional during initial container creation. 

Various folders within an installation. Each container maintains all its data in its 

own folder. Backing up the Containers 

folder backs up all user data. 

Ran on each distributed system from 

the model to install appropriate 

product features and configurations. 

Runs on the Domain Manager to define the 

configurations on logical hosts. The Domain 

Manager handles the provisioning of the 

distributed systems for the specified product 

features. 

Version 8 introduces the Host Manager configuration object, a framework component that 

is hosted in a container on a machine to provide a conduit for remote setup and launching 

of containers. This minimal configuration running on a remote host enables 

administrators to directly set up remote containers that will be automatically provisioned 

for the components that the container hosts. 

The Host Manager is attuned to topology definitions you create in Sonic Deployment 

Manager models, so that you can run the model in a specified environment to create 

configurations that are deployed to specified machines. 



Introducing the Container Launcher Installer 

Version 8 introduces the Container Launcher Installer to install lightweight resources on 

systems that run Sonic 8.0 containers. The Container Launcher Installer can setup a 

container during its installation. The container can include an Activation Daemon and a 

Host Manager as components, and can setup a Windows Service, encrypt the container 

initialization file, and then start the configured container to connect to the domain’s 

Directory Service to insert the configuration. 

How to Script Launcher Installations on Distributed Machines 

The following techniques described in Chapter 1 of the Progress Sonic Installation and 

Upgrade Guide show you how to define a response file with connection information so 

that you can run a script to pick up the local machine’s hostname and use it as the 

container name to configure in the domain’s Directory Service. 

With minimal technical expertise required to enable a machine and its role in a domain’s 

deployment topology, the container launcher removes the complexity of setting up 

distributed computing environment. 

The script gets the hostname, puts in a variable, and then uses the hostname in the key 

variables that an installation to customize: 

● The container name 

● The container path (and folder hierarchy) 

● The Windows Service name 

The adjusted variables are passed into the silent installation as overrides to the values in 

the properties file. 

Container Launcher Installer Can Encrypt Container Boot File 

The 8.0.1 the Container Launcher Installer added a field to the Container Configuration 

Properties panel, INI Encryption Password so that the installer will encrypt the 

container.ini file that it creates in the container’s installation location. 


How Centralized Installation Works 


Consider a domain that involves several machines. First you install the Domain Manager 

on a machine. Then you install the Container Launcher on several other systems, 

specifying that a container is created that defines connection to the Domain Manager, 

includes a Host Manager object, and then starts the container. 

The following illustration depicts two launcher installations that each setup a container 

(ct) with a Host Manager (Hm) and set up a unique name by adding the machine name: 

Domain 

Domain 

Manager 

Mgmt 

Broker 

Directory 

Service 

DomainManager 

Host Manager 

HOST 

MANAGER 

Container 

ctHmmachineone 

Host Manager 

HOST 

MANAGER 

Container 

ctHmmachinetwo 

machinezero machineone machinetwo 

When an administrator defines the containers for replicating brokers, the configurations 

can be pushed through a machine’s Host Manager to set up the container (as illustrated) 



Administration Client 

Tools Application 

and start the brokers. The new brokers will automatically initialize their store and start 

replication—without any additional actions at the remote systems. 

Domain 

Domain 

Manager 

Mgmt 

Broker 

Directory 

Service 

DomainManager 

Container 

ct1 

Container 

ct2 

Host Manager 

HOST 

MANAGER 

Container 


To emphasize how easy that was, consider the case where additional machines are running 

containers with a Host Manager, awaiting provisioning. When a catastrophic failure 

occurs, the ‘lost’ broker can reconfigure its replication connection to new machine, and 

then—by simply setting up and then launching the ‘lost’ broker’s container through the 

74 Progress Sonic Update Bulletin 8.5 

Broker 

br1 

Host Manager 

HOST 

MANAGER 

Container 


Broker 

Backup 

br1 

machinezero machineone machinetwo

Administration Client 

Tools Application 


recovery machine’s Host Manager—recovers the broker and synchronizes with the peer 

that has been standing alone. 

Domain 

Domain 

Manager 

Mgmt 

Broker 

Directory 

Service 

DomainManager 

Broker 

br1 

Container 

ct1 

Host Manager 

HOST 

MANAGER 

Container 


Broker 

Backup 

br1 

Container 

ct2 

Host Manager 

HOST 

MANAGER 

Container 


machinezero machineone machinetwo 

Container 

ct1 

Sonic documentation provides a video demonstration of these steps across multiple hosts 

at How SDM Models Configure Remote Machines for Provisioning. 

Progress Sonic Update Bulletin 8.5 75 

Broker 

br1 

Host Manager 

HOST 

MANAGER 

Container 

ctHmmachinethree 

machinethree


Dynamic Upgrades and Updates to Version 8 Installs 

The Sonic Continuous Availability Architecture provides enterprise deployments with 

resilient, scalable, and virtually 100% production reliability. Previously, when clustered 

and replicated brokers were scheduled for upgrades, they were required to all stop, 

upgrade, and restart. So unscheduled outages could achieve 100% but scheduled 

downtime is still downtime, and service-level agreements often were unforgiving. 

Sonic now allows zero-downtime upgrades of clusters and replicated brokers. Consider 

the SonicMQ deployment topology in the following illustration: 

Administration 

Client 2 

Application 

Tools 

Domain1 

DOMAIN MANAGER 

BROKER 

Messaging 

Broker 

Mgmt 

Broker 

The stages of an upgrade from Version 8.0.x to 8.5 are: 

D S 

A M 

CLUSTER OF BROKERS 

Node B 

Node A 

3 CLUSTER OF BROKERS 4 

Node C 

REPLICATED BROKERS 

Node D 

1. Domain Manager (Node A) — The management node can be upgraded while all its 

brokers and replication functions are running. 

2. Administration Tools — The toolsets that administrators use must stop, get promptly 

upgraded, and then connect to the upgraded Domain Manager. 

3. Standalone Brokers (Node B) — A standalone broker can be running while its 

upgrade is selected. Right-click on a broker’s container’s configuration in the Sonic 

Management Console, and then choose Upgrade. The container will upgrade its 

76 Progress Sonic Update Bulletin 8.5 

1 

CLUSTER OF REPLICATED BROKERS 

P B 

ACTIVE 

PRIMARY 

Messaging 

Broker 

Node C 

P B 

P B 

STANDBY 

BACKUP 

Messaging 

Broker 

6 

Node E 

5


configuration and all its hosted components, provisioning the distributed host with an 

upgraded Launcher and libraries so it will restart in the upgraded version. 

Clusters and replicated brokers are advanced groupings of brokers that are designed 

specifically to ensure continuity and scalability. 

4. Cluster of Brokers (Node C) — All the member brokers of a cluster can be running 

as each broker is upgraded. The cluster tolerates other cluster members that continue 

to run in the prior version, as each one in turn is upgraded. The cluster node never 

stops. 

5. Replicated Brokers (Node D) — When broker replication is functioning, one peer is 

in the ACTIVE mode while the other is in STANDBY mode. The upgrade of the primary 

peer completes by restarting its upgraded version, forcing failover to the peer, and 

then resumption of replication between the peers. Then, when the upgrade of the other 

peer is performed, the upgrade of the node is complete. 

Throughout the upgrade process, the node was always available. Fault-tolerant clients 

handle transitions between the peers, keeping session and transaction states intact. 

6. Cluster of Replicated Brokers (Node E) — Combining the benefits of clusters and 

replicated brokers provides the most resilient and scalable node structure. Implicitly, 

architects of such topologies want zero-downtime. And they can achieve it. 

The Zero-Downtime Upgrade feature takes enterprise resilience to a new level, one where 

staying up to date on product releases, and striving for 100% non-stop processing can both 

be optimized in service level agreements. 



Applying Updates and Patches 

Updates and patches that apply to managed components only require importing the patch 

libraries or applying the update the Directory Service’s Sonic File System, which will 

automatically provision deployed distributed components upon container restart. Any 

additional upgrade or update actions will be performed through the connection to the 

Domain Manager. Administration tools and clients must be updated or patched directly. 

ConfigAdmin utility provides operations to deploy updates and patches 

The ConfigAdmin utility (located in MQ8.5/bin) was enhanced to provide support for 

centrally installing and dynamically deploying upgrades and patches. 

To help support the centralized installation of upgrades and patches, new operations have 

been added for manipulating the Directory Service's Sonic File System: 

import-files 

copy-files 

create-folder 

delete-files 

rename-folder 

rename-file 

New operations have also been added to help centrally manage and optimize the 

incremental deployment of upgrades and patches on a container-by-container basis: 

where: 

copy-ds-files-to-container-caches 

|all-containers [exclude] 

modify-archive-search-path 

|all-containers [exclude] 

● is a text file where each line is one container path 

● [exclude] when specified, uses containers in the list as an exclusion list 


SonicMQ and Management Framework features in 8.0.x 


The following features were introduced in SonicMQ in 8.0 SP 1: 

● “Message Compression” on page 80 

● “Adjusting Time Allowed for Recovery of Shared Subscription Members” on page 82 

● “Custom Branding the Sonic Management Console” on page 82 

● “Skip Initial Connect on Domain Manager Container Startup” on page 84 

The following features were introduced in SonicMQ 8.0: 

● “New Configuration Object: Host Manager” on page 86 

● “Sonic Management Console Runtime Information on Broker Connections” on 

page 87 

● “Enablement of Metrics and Alerts in Configurations” on page 89 

● “IPv6 Support” on page 89 

● “SonicMQ JMS API Tracing” on page 90 

● “Message Grouping” on page 90 

● “Metrics on Temporary Queues” on page 92 

● “Support of JSR 160 Consoles” on page 93 

● “Interbroker Flow Control Notifications” on page 94 

● “HTTP Support for Authentication by an External Security Domain” on page 95 

● “Enable Actional Log Interceptor” on page 95 



Message Compression 

Some throughput problems are caused by large messages and low bandwidth networks. 

Applications that produce and consume messages of significant size over these slow 

networks might improve overall performance by compressing messages. 

The setEnableCompression method in progress.message.jclient.ConnectionFactory 

causes messages produced in the scope of the connection factory to be compressed so that: 

● MessageProducers compress every message before sending it, and the broker 

decompresses every message it receives on these connections. 

● MessageConsumers decompress every message when received because the broker 

compressed every message it delivered to the consumer on these connections. 

When a SonicMQ client application enables message compression, the client negotiates 

with the broker to which it is connecting to agree on the compression characteristics and 

error checking. The actual compression and decompression functions are implicit when 

the option is enabled. 

Message compression has time and space requirements on both the client and the broker. 

An administrator needs to determine which connections can offset the compression 

overheads with the savings in message transfer time, and how many connections that 

enable compression can be supported by the broker’s resources. 

The following syntax enables message compression on a connection factory: 

ConnectionFactory.setEnableCompression(boolean value) 

For example: 

javax.jms.ConnectionFactory factory; 

factory = (new progress.message.jclient.ConnectionFactory (broker)); 

factory.setEnableCompression(true); 

connect = factory.createConnection (username, password); 

This information has been added to the “SonicMQ Connections” chapter of the Progress 

SonicMQ Application Programming Guide. 



Setting Message Compression on Administered Objects 

The Administered Objects Tool has been enhanced to enable maintenance of message 

compression in the following new section of the Advanced tab for Connection Factories: 

where: 


Enable 

Compression 

Custom 

Compression 

Factory 

When selected, requires connections that use this connection factory to 

perform message compression before sending messages, and requires 

the broker to deliver compressed messages to connections that use this 

connection factory. The setting could be overridden by the client. 

Specifies the custom class that defines message compression and 

decompression. 

This information has been added to the “Using the JMS Administered Objects Tool” 

chapter of the Progress SonicMQ Configuration and Management Guide. Message 

compression parameters have also been added to ESB Connections and the Sonic 

Deployment Manager schema. 



Adjusting Time Allowed for Recovery of Shared Subscription Members 

A new advanced broker property can be implemented. 

BROKER_PUBSUB_PARAMETERS.SHARED_SUBS_RECOVERY_TIMEOUT — Enables adjustment of the 

number of milliseconds that members of a group of shared subscribers will wait for 

resolution of indoubt messages to fault-tolerant members that are recovering (from client 

failure or broker failover) before reallocating any such messages to other group members. 

The default value is 60000—60 seconds. Setting this property to a higher value reduces 

the likelihood that a recovering group member receives messages that have already been 

reallocated to another member. 

The timer starts when the first recovering member reconnects to the group. While the 

group has members with indoubt resolution pending, all delivery to the group is deferred, 

and all new received messages are saved into the database for the group to be delivered 

when doubt is resolved, SHARED_SUBS_RECOVERY_TIMEOUT is reached, or all indoubt faulttolerant 

group members pass their reconnect timeout. 

The timer starts generating messages about the group’s status to the log after thirty 

seconds to note how many fault-tolerant members are being resolved. Subsequent entries 

note when resolution completes, or the number of unresolved members after the timeout. 

This information has been added to the “Configuring Brokers” chapter of the Progress 

SonicMQ Configuration and Management Guide where the Advanced tab is discussed. 

Custom Branding the Sonic Management Console 

The title and the graphics that identify Sonic in the Sonic Management Console can be 

changed to your preferred title and graphics. 

◆ To brand the Sonic Management Console: 

1. To change the title displayed: 

a. Use your preferred text editor to open the file: 

sonic_install_dir/MQx.x/bin/branding.properties. 

b. Change the value of application.title to your preferred name. 

c. Save the edited file. 

2. To change the icons and logo displayed: 

a. Produce your graphic files as .gif files: 

❑ Logo (200 x 117 pixels) named logo.gif 



❑ Large icon in title bar (36 x 36 pixels) named Application.gif 

❑ Small icon in title bar (18 x 18 pixels) named Application18.gif 

b. Copy your graphics files. 

c. Replace the files of the same name in sonic_install_dir/MQx.x/bin. 

Note You can use your preferred name for these graphics files by adding their .gif files 

to the SonicMQ /bin directory, and then correspondingly changing their name 

references in the branding.properties file. For example: 

application.logo=eglogo.gif 

application36.icon=egApplication.gif 

application18.icon=egApplication18.gif 

3. When you start the management console, your changes are applied. For example: 



4. When you choose Help > About in the management console, your logo is displayed. 

For example: 

This information has been added as the appendix “OEM Considerations” in the Progress 

SonicMQ Configuration and Management Guide. 

Skip Initial Connect on Domain Manager Container Startup 

At startup of the Domain Manager, you usually see a warning logged, as shown: 

[date 13:25:00] (info) "Domain1.DomainManager" starting... 

[date 13:25:10] (warning) Management connect failure: 

java.net.ConnectException: Connection refused: connect: tcp://myhost:2506 

[date 13:25:10] (info) ...connect failed, retrying... 

[date 13:25:10] (info) Loaded ID=AGENT 

As the management broker has not yet started, this is a benign error but it wastes ten 

seconds. A new Java System Property is introduced to skip the initial attempt at 

connection that Domain Manager attempts before its broker is ready. 

The Java System Property is entered on the Environment tab of a Domain Manager’s 

container by clicking New. The property is entered as follows: 



Note the a -D is implicit—it will be prepended when the property is on the commandline. 

With the System Property sonicsw.mf.skipInitialConnect set to true, at container restart 

you see: 

[date 13:35:00] (info) "Domain1.DomainManager" starting... 

[date 13:35:01] (info) Loaded ID=AGENT 

This information has been added to the “Configuring Containers and Collections” chapter 

of the Progress SonicMQ Configuration and Management Guide where the Environment 

properties are discussed. 



New Configuration Object: Host Manager 

A new configuration object, Host Manager, is introduced in Sonic 8.0. A Host Manager 

is a framework component that implements an interface for remote methods in the 

installation location where a management container that has the Host Manager as a 

component is running. A Host Manager can: 

● Launch containers at its remote location. 

● Setup configured containers at its remote location. 

A Host Manager can be added as a component of a container configured during a Sonic 

Launcher installation. You can also create a Host Manager in the SMC and add it to 

containers. 

The Sonic Deployment Manager uses Host Manager objects to resolve physical hosts with 

a model’s Topology.xml file to locate machines and logical hosts as physical machines on 

which it can communicate to perform operations. 

You can use a Host Manager interactively in the Sonic Management Console to perform 

container setup and container launching on the machine where the Host Manager is 

running. In the following illustration, the Host Manager in ct1 is being used to setup the 

configured container ct2 on ct1’s host: 

Management APIs are available that enable you to use a Host Manager for additional 

functions. 

See the “Managing Containers and Collections” chapter of the Progress SonicMQ 

Configuration and Management Guide, and the Sonic Deployment Manager User’s Guide 

for more information. 



Sonic Management Console Runtime Information on Broker 

Connections 

Broker connections now let you drill down into connections, their sessions, and message 

consumers. In the Sonic Management Console, choose the Manage tab, and then 

Connections on a running broker. Right-click to choose Show System Connections. 

The Details tab on the selected connection shows information at the level you select, as 

shown: 

The broker that is being viewed is a management routing node, acting as a local 

management connection for other containers. As such, it has subscriptions to containers 



that route through it to the management node, and the management node connection. The 

Subscriptions tab provides information about subscriptions by the selected broker, as 

shown: 

For more about seeing broker connection information in the Sonic Management Console, 

see “Managing SonicMQ Broker Activities” in the Progress SonicMQ Configuration and 

Management Guide. 

ConnectionTree Sample Applications 

Sonic’s Runtime API also provides visibility into connections, sessions, and message 

consumers in the ConnectionTree Java proxy and JavaScript samples. 

The samples demonstrate extraction of a list of currently active brokers in the domain 

using the getActiveBrokers() method, and use of connection-related management API's: 

IBrokerProxy.getConnections() 

IBrokerProxy.getConnectionTree() 

IBrokerProxy.getConnectionMemberDetails() 

BrowseConnections Sample Application 

The BrowseConnections sample application and its Java source code demonstrate a GUI 

that lets a user navigate through a connection in GUI windows. 

For more information about the API and the samples, see “Using the Runtime API for the 

Sonic Management Environment” in the Progress SonicMQ Administrative Programming 

Guide. 



Enablement of Metrics and Alerts in Configurations 

Previously, all metrics and alerts were runtime settings that persisted across container 

shutdowns. The technique has changed so that Sonic’s metrics and alerts can be enabled 

at configuration time or runtime. Metric and alert enablement at runtime will not persist 

across container or component restarts. Certain limitations apply when enabling at 

configuration time: 

Runtime settings override the configured settings. Runtime settings are not persisted. 

See “Monitoring the Sonic Management Environment” in the Progress SonicMQ 


IPv6 Support 

Configure Manage 

Metrics Non-Instance Yes Yes, overrides Configure 

Instance Patterns Yes Yes, overrides Configure 

Alerts Non-Instance Yes Yes 

Instance Patterns Yes Yes 

Notifications Instance Patterns No Yes 

For a platform (hardware, JVM, and system configuration) that supports IPv6, you can 

define acceptors in IPv6 syntax. The following excerpt shows loopback addresses in IPv4 

and IPv6 (for use in development and testing) and well-formed URLs for IPv4 and IPv6: 

Note Limitations to IPv6 Support — Some systems have problems with IPv6 that cannot be 

addressed in currently supported JVMs. Specifically, Sonic 8.0 does not support IPv6 on 

Windows for areas of SonicMQ that use NIO, namely: 

● Directory Service replication 

● HTTP Tunnelling acceptors 



SonicMQ JMS API Tracing 

Tracing is now provided for SonicMQ Java applications. The trace levels cover exception 

tracing, entry tracing, and instance, argument and exit tracing. The following shows the 

display when the Chat sample is set to entry tracing: 

C:\Program Files\Progress\Sonic\MQ8.0\samples\TopicPubSub\Chat> 

..\..\SonicMQ Chat -u SALES 

[timestamp] entering Connection javax.jms.ConnectionFactory.createConnection(String, String) 

[timestamp] entering Session javax.jms.Connection.createSession(boolean, int) 

[timestamp] entering Session javax.jms.Connection.createSession(boolean, int) 

[timestamp] entering Topic javax.jms.Session.createTopic(String) 

[timestamp] entering MessageConsumer javax.jms.Session.createConsumer(Destination) 

[timestamp] entering void javax.jms.MessageConsumer.setMessageListener(MessageListener) 

[timestamp] entering MessageProducer javax.jms.Session.createProducer(Destination) 

[timestamp] entering void javax.jms.Connection.start() 

Enter text messages to clients that subscribe to the jms.samples.chat topic. 

Press Enter to publish each message. 

Hello world. 

[timestamp] entering TextMessage javax.jms.Session.createTextMessage() 

[timestamp] entering void javax.jms.TextMessage.setText(String) 

[timestamp] entering void javax.jms.MessageProducer.send(Message) 

[timestamp] entering void Chat.onMessage(Message) 

[timestamp] entering String javax.jms.TextMessage.getText() 

SALES: Hello world. 

Ctrl+C 

[timestamp] entering void javax.jms.Connection.close() 

Tracing has no overhead when it is not in use. Load-time weaving—adding the tracing 

code when the class is being loaded by the class loader—means that the aspect was not 

present when the application was compiled. So when load-time weaving is not 

configured, the application performs as if tracing code did not exist. 

See Appendix B of the Progress SonicMQ Application Programming Guide for 

discussion of the setup and tracing levels of JMS tracing. 

Message Grouping 

Message grouping—defined by the message producers sending to specifically configured 

queues on the broker—provides a mechanism that you might think of as dynamic 

exclusive subqueues. 

The producer sets a property with a message’s group value, and sends the message to the 

broker. This feature must be enabled on a SonicMQ broker on a per-queue basis before 



message grouping can occur. Each queue configuration enables message group 

dispatching of messages to receivers and specifies the property that will determine the 

grouping of messages. The default property is JMSXGroupID as shown on the following 

queue’s Message Groups tab: 

Important When message group handling is enabled on a queue, message selectors on that queue are 

not valid. Applications that receive messages on a queue that is enabled for message 

grouping will fail if the application uses message selectors. 

The broker determines whether it has an assigned active receiver for the message’s group. 

If it does, the message goes to the assigned receiver. If it does not, it assigns a receiver to 

the group name. 

This feature provides advantages when the incoming messages are for diverse groups with 

arbitrary names that handle a reasonable number of messages. The limitation is that, like 

exclusive queue receivers, when the backlog on a message group’s receiver gets huge, you 

cannot add receivers to balance the load. 

A SonicMQ sample application is provided, MessageGroupTalk, and the SDM sample 

model MessageGrouping describes how models can set the message grouping parameters 

on a queue. The sample application demonstrates advantages of message grouping: 

● Auto load balancing — Message groups automatically load balances messages. An 

additional sender to a new group and a new receiver on the queue show that the new 

receiver handles messages from the new sender. 



● Consumer affinity — The receivers in the sample show that the messages each 

receives are for their assigned group, and that a message group is always associated 

with the same receiver while the broker is running. 

● Message ordering within a group — The receiver’s let you observe that their 

messages for an assigned group always arrive in the order they are sent. 

● Automatic failover — When you shutdown a receiver, and then send messages to 

groups that the stopped receiver was assigned, you see that the message group is 

assigned to another receiver. 

See the “Point-to-point Messaging” chapter in the Progress SonicMQ Application 

Programming Guide for more information on producers and message grouping general 

concepts. 

See the “Configuring Queues” chapter of the Progress SonicMQ Configuration and 

Management Guide for details on the queue settings for message grouping. 

Metrics on Temporary Queues 

For queue metrics, you can select Show Temporary Queue Instances to also list instances 

of temporary queues, as shown: 

See the “Instance Metrics” section of the “Monitoring the Sonic Management 

Environment” chapter of the Progress SonicMQ Configuration and Management Guide. 

Using Patterns to Filter Temporary Queues for Metrics 

You can define patterns to select TemporaryQueues if the temporary queues were created 

using an overload of the Session.createTemporaryQueue() method lets you supply a 

preferred name in a CustomID String, Session.createTemporaryQueue(String customID). 



See “Temporary Queues” in the “SonicMQ Client Sessions” chapter of the Progress 

SonicMQ Application Programming Guide for more information about setting custom 

identifiers on temporary queues. 

Support of JSR 160 Consoles 

Progress Sonic provides a JSR 160 connector client to enable JMX consoles such as 

JConsole to connect to a managed Sonic JVM instance to gain visibility into JVM 

behaviors and limited access to Sonic components running in the JVM. 

Sonic limits the access to Sonic components so that the advanced security features Sonic 

provides in its administrative tools—Sonic Management Console and management 

applications—are not compromised. Those features include authentication, authorization, 

encrypted communications, and fine-grained management permissions. 

Each item in the Sonic container exposes three sets of Sonic MBean data: Attributes, 

Operations, and Notifications. The following screen is an example of Attributes. 

Management permissions might limit your ability to make changes. When auditing is 

enabled in the Domain Manager, changes are recorded in the audit trail. 

See the “Using JSR 160 Compliant Consoles” chapter of the Progress SonicMQ 




Interbroker Flow Control Notifications 

Flow control notifications might show that an interbroker (cluster) connection is causing 

publishers to flow-control, but the notifications do not provide enough information to 

determine why the interbroker connection is blocked. This enhancement extends flow 

control notifications to include notifications for blocked interbroker connections, 

including identification of the consumers and destinations that are causing the flow 

control condition. 

The property Flow Control Monitor Interval is enabled by default on a cluster, as shown: 

The default value is 15 seconds. A value of 0 means that the brokers will not be monitored 

for flow control. The management property is dynamic: when the monitor interval is 

changed, it will take a couple monitor intervals for the change to be reflected in the 

notifications. 

For details about the setting, see the “Clusters” section of the “Configuring SonicMQ 

Brokers” chapter of the Progress SonicMQ Configuration and Management Guide. 

See also “Enabling Flow Control Notifications on a Cluster” in the Progress SonicMQ 

Administrative Programming Guide for information about setting interbroker flow 

control notifications with the configuration parameter CLUSTER_FC_MONITOR_INTERVAL. 

When a cluster has a positive Flow Control Monitor Interval value, the cluster will provide 

two notifications: a pause notification to note that a broker connection is unable to send 

messages, and a resume notification to note that sending has resumed. 



For details about the notifications, see the “Broker Notifications in Clusters” section of 

the “Managing SonicMQ Brokers” chapter of the Progress SonicMQ Configuration and 

Management Guide. 

For details about the setting, see the “Clusters” section of the “Configuring SonicMQ 

Brokers” chapter of the Progress SonicMQ Configuration and Management Guide. 

HTTP Support for Authentication by an External Security Domain 

HTTP clients can use SonicMQ’s Pluggable Authentication and Security Service (PASS) 

feature, enabling an external security domain for user authentication and authorization— 

provided that the broker on which the acceptors are defined is configured to use an 

external security domain. See the “HTTP(S) Direct Acceptors and Routings” chapter of 

the Progress SonicMQ Deployment Guide for more information. 

Enable Actional Log Interceptor 

Actional 8.0 introduced a new kind of interceptor, the Actional Logging interceptor. This 

interceptor allows for the reporting of application logs which correlate to intercepted 

interactions. Sonic has created a Sonic Logging interceptor to augment the Actional 

logging interceptor so that messages originating from the Sonic logging framework can 

also be captured through Actional. 

Container configurations can create application log entries that correlate to intercepted 

interactions, and record the entries in the Sonic logging framework by selecting the option 

Enable Actional Log Interceptor on the container’s Logging and Auditing tab. 

Then, you must specify two Java system properties on the container’s Environment tab to 

modify the interceptor’s behavior: 

● com.progress.sonic.actional.soniclog.maxMsgSize 

● com.progress.sonic.actional.soniclog.disableLogOutput 

This feature requires a Progress Actional Agent running on the local system. See your 

Progress representative for more information. 

For details about setting container properties, see the “Configuring Containers and 

Collections” chapter of the Progress SonicMQ Configuration and Management Guide. 

CONNECT_PING_TIMEOUT No Longer Defaults to Indefinite 

The advanced broker property CONNECTION_TUNING_PARAMETERS.CONNECT_PING_TIMEOUT 

provides a mechanism to force an existing connection to disconnect if it does not respond 



to a ping in the specified timeout interval (in milliseconds). A setting of zero (0) specifies 

immediate disconnection of the existing connection. If this property is not set, a Version 

7 broker would assume the default behavior of blocking indefinitely until either the ping 

succeeds or the socket fails. In SonicMQ 8.0, if this property is not set, the broker uses the 

default value of 30000 (30 seconds.) 

Default SSL is JSSE; RSA requires business arrangement 

Sonic’s transition away from supplying RSA SSL by default involves several changes. 

RSA SSL is optional 

SonicMQ SSL relies entirely on JSSE. If you have a business arrangement with RSA 

Security, you can add the RSA libraries to the broker locations and then enable the broker 

to use RSA SSL. If you are using Certificate Revocation Lists (CRLs), you need to use 

RSA libraries. 

Runtime Support for RSA-to-JSSE Migration 

For large deployments, it might not be feasible to manually convert all existing certificate 

and private keys into the key stores and/or trust stores that are supported by JSSE. You 

would also have to modify your configuration to reflect the use of new JSSE key store 

and/or trust store and equivalent JSSE cipher suite(s). 

To handle these tasks, Sonic’s JSSE functionality will: 

● Populate JKS key stores from PKCS7 encoded certificates and PKCS8 encoded 

private keys 

● Populate JKS trust stores from x.509 certificates 

● Map RSA cipher suite(s) to equivalent JSSE cipher suite(s) on the fly. 

By default, this runtime mapping/conversion will take place if the broker is configured to 

use the RSA SSL provider. Runtime conversion and mapping takes place on the broker as 

well as on the client if—and only if—a JSSE-based Keystore and Truststore is not 

configured. 

Populating JSSE Key Store from PKCS7 Certificate Chain & PKCS8 

Private Key 

When starting a SSL acceptor or opening an outbound SSL connection, certificates and 

private keys configured with the RSA SSL provider will be loaded by the broker to 



populate a JSSE key store. The transient in-memory key store will not be written back 

to the disk. 

Populating JSSE Trust Store from X.509 Certificates 

A truststore is a special purpose keystore that is used to decide what entities to trust. When 

the SSL client authentication is enabled for an acceptor, the CA certificates with the RSA 

SSL provider will be loaded by the broker to populate a JSSE trust store to validate the 

client certificates. The transient in-memory trust store will not be written back to the disk. 

Cipher Suites Mapping 

During upgrade, the list of cipher suites will be modified to reflect the migration from 

RSA to JSSE. Likewise, all cipher suites will be identified using the standard cipher suite 

names listed in Sun's JSSE Reference Guide. 

Important Unsupported RSA Cipher Suites — The following RSA cipher suites can not be mapped 

to any equivalent JSSE cipher suites: 

● RSA_With_RC2_CBC_MD5 

The following RSA suites provide key exchange without authentication: 

● DH_DSS_Export_With_DES_40_CBC_SHA 

● DH_DSS_With_AES_128_CBC_SHA 

● DH_DSS_With_AES_256_CBC_SHA 

● DH_RSA_With_AES_128_CBC_SHA 

● DH_RSA_With_AES_256_CBC_SHA 

The following suite is a no-op: 

● Null_With_Null_Null (no-op) 

Certificate Conversion Utility 

A utility tool lets you convert existing private keys and certificates into a JSSE key store 

or trust store on the disk. Using this utility, you can: 

● Convert PKCS7 certificate chain and encrypted PKCS8 private key into a JKS key 

store. 

● Convert PKCS7 certificate chain and encrypted PKCS8 private key into a PKCS12 

key store. 

● Convert a list of trusted CA certificate into a JKS trust store. 



See “Using the RSA to JSSE Migration Tool” in the “SSL and HTTPS Tunneling 

Protocols” chapter of the Progress SonicMQ Deployment Guide for more information. 

After the conversion, the SSL settings must be updated accordingly to point to the 

corresponding Keystore and Truststore. 

Certificate Manager Tool No Longer in the Management Console 

The Sonic Management Console no longer provides a Certificate Manager Tool. 

Client SSL Settings 

Client side SSL setting uses Java system properties. For the 8.0 release, the SSL client 

runtime will default to JSSE in the absence of the SSL_PROVIDER_CLASS property. Clients 

not using the SSL provider property require no changes, and no action is needed. 

To switch/migrate from RSA SSL to JSSE after upgrade, change the SSL Provider 

property to JSSE (or simply remove it) and leave all other SSL settings unchanged, for 

example: 

-DSSL_PROVIDER_CLASS= progress.message.net.ssl.jsse.jsseSSLImpl 

To continue to use RSA SSL after upgrading (and licensing with RSA for the libraries), 

leave all SSL settings unchanged, for example: 

-DSSL_PROVIDER_CLASS= progress.message.net.ssl.jsafe.jsafeSSLImpl 

Improved Tuning Information for Platform Fast Failover 

Field personnel that have been achieving optimal fast failover for our customers suggested 

adding, removing, and changing the recommendations. Settings that are discussed are, on 

Windows, TcpMaxDataRetransmissions and TcpMaxConnectRetransmissions, and, on 

Linux, tcp_retries2 and tcp_syn_retries. 

This revised information is in the “Tuning TCP to Optimize CAA Failover” chapter of the 

Progress SonicMQ Performance Tuning Guide. 



C Client: Releasing Objects and Avoiding Memory Leaks 

This section in Progress SonicMQ C Client Guide 8.0 was enhanced at customer request. 

When you finish with an HOBJ, you must explicitly call a release method and give it an 

object reference as in this excerpt from the Talk.c sample application: 

Code Sample 1. Releasing Objects 

/* Clean up. Order doesn't matter. */ 

if (msg) 

Message_release(msg, &retval); 

/* SonicMQ allocated this one, so "release" it. */ 

if (textObj) 

String_release(textObj, &retval); 

/* Application allocated this one, so "free" it. */ 

if (text) 

free(text); 

If you do not release the HOBJs, remaining references will cause memory leaks. Note that 

all *_release API are mapped to Object_release so that Object_release can be called to 

release any HOBJ. 

Also, be sure to close and destroy connections or they will cause memory leaks. The 

correct sequence is to close the producer (publisher or sender), then the session, and then 

the connection. 

Every _release() function decrements its argument object’s ref count, and objects are 

destroyed when their ref counts reach 0. When you are done with an HOBJ, release it— 

if the Sonic Client runtime needs a reference to that object, it will keep that reference and 

your _release will not destroy the object. If the runtime needs to copy the contents of the 

object into some other representation, it will do it and will not keep a reference to the 

original object so that your _release() will destroy the object (provided that it was the last 

reference to it.) 

In summary, release HOBJs when your code does not need them anymore and trust the 

runtime to do the right thing. (In much the same way that the Win32 API exposes kernel 

objects via handles to them and operations on those handles.) 

This revised information in the “Programming with the C Client” chapter of the Progress 

SonicMQ C Client Guide. Also, a C code example is listed there that sets and then releases 

string properties. You can copy the example’s text, build it, and then try it. 



Sonic ESB and Workbench features in 8.0.x 

The following features were introduced in Sonic ESB in 8.0 SP 1: 

● “Process Continuations” on page 101 

● “Message Compression Parameters for ESB Connections” on page 105 

● “Additional New Init Parameters for ESB Connections” on page 106 

● “New Tuning Configuration Options for Sonic Connect Services” on page 106 

● “Support for Expressions in XPath Routing Rules” on page 107 

● “Resubmit Count is Exposed in Workbench” on page 106 

● “Support for Expressions in XPath Routing Rules” on page 107 

The following features were introduced in Sonic ESB Version 8.0: 

● Full Support for RESTful Web Service Development and Integration — Invoke and 

implement RESTful Web services using the Sonic Connect service. This functionality 

is documented under “Working with RESTful Web services” in the “Progress Sonic 

Workbench User Guide” section of the Sonic Workbench online help. 

● Full Support for Open, Fully Standards-Compliant Programming Model — Develop 

applications for the Sonic ESB that take advantage of an open, fully standardscompliant 

programming model, consisting of the following features: 

■ New Web Services Stack Based on Market Leading Apache CXF — Invoke and 

implement Web services using the Sonic Connect service, giving you improved 

performance, greater ease of use, and more complete standards support. 

■ Ability to Host JAX-WS and JAX-RS POJOs in a Sonic ESB Container — Hosting a 

JAX-WS/JAX-RS POJO in an ESB container provides a number of benefits 

including centralized management, load balancing, and optimized access to the 

implemented resources from ESB processes 

This functionality is documented under “Working with WS-* Web services” and 

under “Working with RESTful Web services” in the “Progress Sonic Workbench User 

Guide” section of the Sonic Workbench online help. 

The following features were also introduced in Sonic ESB in 8.0: 

● “Improved Fault Handling within ESB Processes” on page 114 

● “Message Mapping” on page 115 

● “Fault Handling with Sonic Interceptors” on page 116 

● “Service Configuration Editor” on page 117 

● “Sonic Connect Projects” on page 117 


● “Sonic Connect Editor” on page 118 

● “Dispatch Service Step” on page 119 


● “Flow Termination Steps” on page 120 

The following changes were introduced in Sonic ESB in 8.0 SP 1: 

● “Change: WS-RM Processing is Disabled by Default” 

● “Change: Spring Configuration Changes for JAX-WS POJOs” 

Process Continuations 

This new feature includes an API and a sample. 

When modeling ESB processes, you can use process continuations to: 

● Save the state of a running process instance 

● Terminate the process instance 

● Continue the process instance at a later time using the saved process state 

This new feature includes an API and a sample. 

Process state is stored in XQProcessContinuation objects. After saving process state to an 

XQProcessContinuation object, you can choose where you want the process to continue. 

You do not have to resume execution in the same thread, service, or container where the 

process originally executed; you can continue execution in a different thread, service, or 

container altogether. You can also change the process state before saving it—for example, 

you can change the next step, which determines where the process should resume 

execution. 

The term passivation refers to the combined actions of saving (and possibly modifying) 

the process state and then terminating process execution. The term activation refers to the 

combined actions of retrieving the saved process state and using it to continue process 

execution. 



An XQProcessContinuation object stores up to three levels of process state, described in 

the following table. Depending on the level, the size of the XQProcessContinuation object 

can vary from a few bytes (level 0) to a few kilobytes (level 2). 

Level Description 

0 At this level, the XQProcessContinuation object contains a minimal set of process 

state, such as the name of the process and the next step. If the process instance is a child 

process, the process state at this level also includes the 0 name of the top-level process 

and the composite name of the child process and its next step. All other process 

context—for example, exit, RME, and fault endpoints; process context properties; and 

tracking information—is lost. 

1 At this level, the XQProcessContinuation object contains the level-0 information plus 

all other process context information. You can access the additional process context by 

calling the XQProcessContinuation.getProcessRuntime() method. 

2 At this level, XQProcessContinuation object contains the level-1 information plus 

other information about the itinerary. Level 2 is useful if you expect the process 

definition to change between the time the process is passivated and activated. Large 

continuation objects at this level are not ideal for including as message headers but are 

suitable for other persistence use cases. 

Process continuations are useful whenever you want to interrupt process execution and 

resume it at a later time. Process continuations can facilitate the handling of asynchronous 

responses, if you want to interrupt process execution after sending the request. For 

example, suppose that an ESB process step invokes a long running process—a process 

that takes hours or possibly days to generate a response. Using process continuations, you 

can model this invocation as a one-way request and pass the continuation as a message 

header in the one-way request, and then you can passivate the calling process. When, at 

some future time, the response is returned with the continuation header, another ESB 

process or service can listen for the response and then activate the original calling process, 

allowing it to resume execution where it left off. 

How Process Continuations Work 

After you identify an ESB process whose execution you want to interrupt and resume at 

a later time, you must add a service step to the ESB process—a step that invokes a custom 

service responsible for passivation. You must also implement this passivating service. In 

your implementation, the service must obtain an XQProcessContinuation object and 

modify its contents as needed (for example, to specify the step in the process where 



execution should continue when the ESB process is activated). Your implementation must 

also decide what to do with the XQProcessContinuation object in the gap of time after 

passivation and before activation. Depending on your particular use case, you might 

decide to persist the XQProcessContinuation object to a database, serialize it to a file, or 

add it to a message header of the outgoing message. If you want to persist the object to a 

database or serialize it to a file, you must also create a class that implements the 

XQProcessContinuationHandler interface. If you want to add the continuation object to a 

message header, you can use the MsgHeaderContinuationHelper class, which already 

implements the XQProcessContinuationHandler interface. This class transforms the 

XQProcessContinuation object into a Base64-encoded string and adds it as a header to the 

outgoing message. (The process continuation sample uses the 

MsgHeaderContinuationHelper class to add the continuation object to a message header.) 

When modeling the ESB process, you must also decide how to terminate its execution, 

which is the final stage of passivation. You can terminate the ESB process either by 

explicitly adding a terminate step or by implementing the passivating service in such a 

way that it adds no messages to its outbox. (The process continuation sample uses a 

terminate step to terminate process execution.) 

After deciding how you want to implement passivation, you must implement a custom 

service that is responsible for activation. How you implement the activating service 

depends on your passivation strategy. For example, if you chose to persist 

XQProcessContinuation objects to a database, then you might choose to implement a 

database-polling strategy to retrieve the objects from the database. Similarly, if you chose 

to serialize the XQProcessContinuation objects to the file system, then you might choose 

to implement a file-polling strategy. (The process continuation sample retrieves the 

XQProcessContinuation object from a message header using the 

MsgHeaderContinuationHandler class.) You might also create a correlation id, and then use 

that correlation key to retrieve the continuation based on some external event like a timer 

going off, a message arriving on an async transport, and so on. 

Note The passivating and activating services can be implemented as a single custom service. 

Separating them into two custom services is not required. In fact, the process 

continuation sample uses a single service both for passivation and for activation. 

After retrieving the XQProcessContinuation object, the activation service uses the 

information in the object to continue (activate) the ESB process. The service calls the 

XQServiceContext class's getProcessContinuationAddress(XQProcessContinuation 

continuation) method to obtain an XQAddress object. The service then creates an 

XQEnvelope object where the XQAddress object is the only address in the envelope and puts 



the envelope into the service's outbox by calling the XQServiceContext class's 

addOutgoing(XQEnvelope env) method. 

In summary, process continuations require the coordinated actions of the following 

artifacts: 

● A calling ESB process — An ESB process whose execution is interrupted and whose 

state is passivated. This process must: 

■ Invoke a custom service that is capable of passivating the process continuation 

information. 

■ If necessary, provide conditional logic to terminate process execution. This logic 

can, for example, test for the presence of the continuation header in the inflight 

message; if the header is present, the process can branch to a terminate step. 

Depending on how the passivating service is implemented, the calling ESB 

process might not have to add a terminate step—for example, if the passivating 

service adds no messages to its outbox, the calling ESB process will effectively 

terminate when the service call returns. 

■ Continue execution after being resumed by an activating ESB service or process. 

A passivating service — A custom service that is responsible for: 

■ Using the XQProcessContext.getContinuation() method to obtain an 

XQProcessContinuation object. This object contains all of the continuation 

information for the calling ESB process. 

■ Calling the XQProcessContinuation.setStepName(String stepName) method, 

whose purpose is to specify where in the calling ESB process execution should 

resume. 

■ Optionally making other changes to the XQProcessContinuation object. 

■ Implementing a strategy for temporarily saving the XQProcessContinuation object 

until it is used to activate the calling ESB process. To do this, the service must 

invoke the save(XQMessage message, XQServiceContext serviceContext, 

XQProcessContinuation continuation) method of a class implementing the 

XQProcessContinuationHandler interface. 

An activating service — A custom service that is responsible for: 

■ Calling the retreive(XQMessage message, XQServiceContext serviceContext) 

method of a class implementing the XQProcessContinuationHandler interface. 

This method returns an XQProcessContinuation object. 

■ Optionally making other changes to the XQProcessContinuation object. 



■ Calling the getProcessContinuationAddress(XQProcessContinuation 

continuation) method of the XQServiceContext class to obtain an XQAddress 

object indicating where the calling ESB process should resume execution. 

■ Placing the inflight message into the activating service's outbox (the message 

must be the only one in the outbox), causing the ESB to deliver the message to 

the XQAddress returned by the 

getProcessContinuationAddress(XQProcessContinuation continuation) 

method. 


and in its PDF version, Sonic ESB Developer's Guide. In addition, those locations detail 

the Process Continuations API and the new sample. 

New Sample for Process Continuations 

The sample shows how you can use continuations to model potentially long running 

processes that can continue processing after receiving asynchronous responses. The 

sample contains a Sample.Continuation.LongRunning process that simulates sending a one 

way invocation and then continuing the process after receiving the asynchronous 

response. For more information about running this sample, see the readme.txt file in the 

Continuation folder. 

Message Compression Parameters for ESB Connections 

In the Sonic Management Console, the ESB Configured Objects definition supports 

message compression in ConnectionFactoryParameters parameter: 

● Enable Compression — When selected, requires connections that use this connection 

factory to perform message compression before sending messages, and requires the 

broker to deliver compressed messages to connections that use this connection 

factory. The setting could be overridden by the client. 

● Custom Compression Factory — Specifies the custom class that defines message 

compression and decompression. 

This information has been added to the “ESB Endpoints and Connections” chapter of the 

Progress Sonic ESB Configuration and Management Guide. 

See “Message Compression” on page 77 for more information about this new feature. 



Additional New Init Parameters for ESB Connections 

The Init Parameters on the Connections tab of a SonicMQ Endpoint configuration now let 

you set parameters that were previously available on Administered Objects but not in 

endpoint configurations: 

● Enable load balancing — Select to enable the requested connection to be redirected 

for load balancing if necessary. If not selected, the requested connection cannot be 

redirected. 

● Monitor Interval — When flow control blocking is sustained, an application producer 

session can be prevented from producing messages for a significant period of time; 

that time is the monitoring interval. The Flow Control Monitor Interval defines the 

duration of the monitoring interval as a non-negative integer number of seconds. A 

value of 0 indicates that flow control monitoring is disabled for all sessions on the 

connection. The default value is 60 seconds. 

● Socket Connect Timeout — Sets a timeout on the socket after a specified time 

interval. Enter the positive integer number of milliseconds before a connection 

attempt should time out. Setting the value to 0, the default value, means to never time 

out. See the chapter “SonicMQ Connections” in the Progress SonicMQ Application 

Programming Guide for more information about this feature. 

New Tuning Configuration Options for Sonic Connect Services 

Sonic Connect now supports configuration properties to tune the number of available 

HTTP connections and server threads. The default properties file for a Sonic Connect 

service will include properties for these options where appropriate: 

● For an exposed Web service or RESTful Web service, the http.maxServerThreads and 

http.minServerThreads properties are used to determine the number of available 

threads for serving requests. 

● For a Web service or RESTful Web service client the http.maxConnections property 

can be used to constraint the number of concurrent HTTP connections. 

See Working with RESTful Web services for more about Sonic Connect thread/connection 

tuning. 

Resubmit Count is Exposed in Workbench 

For a resubmit step, you can now define an optional Number of resubmit attempts 

parameter. See the Progress Sonic ESB Developer's Guide for details on how the resubmit 

count affects fault handling. 


Support for Expressions in XPath Routing Rules 


This release introduces an additional source for running XPath rules in the XCBR file. 

You can now specify an expression. With the use of standard Sonic expressions, this 

feature enables you to route based on process context properties, contents and headers of 

the message, properties in a property file, container deployment property and System 

properties. Refer to the Progress Sonic ESB Developer's Guide for the expression syntax. 

Change: WS-RM Processing is Disabled by Default 

By default, support for WS-RM (WS Reliable Messaging) is disabled in ESB. If you use 

WS-RM then you must configure the Process Engine to enable WS-RM for your ESB 

processes. Refer to release note SNC00078507 for how to apply this configuration change. 

Change: Spring Configuration Changes for JAX-WS POJOs 

There are some changes to the generated spring configuration for deploying a JAX-WS 

POJO to a Sonic Connect service. Sonic Connect services created with Workbench 8.0 

that host JAX-WS POJOs must be updated and then redeployed. Refer to release note 

SNC00078898 for details on modifying your spring.xml file. 

Improved Documentation: Tailoring With PropertyMaps and the 

artifactName Attribute 

The following material was added or revised in the “Adjusting Tailoring Rules to Apply 

When Creating Map Files” section of the “Mapping ESB Artifacts to Target Domains” 

chapter of the Progress Sonic ESB Deployment Guide. 

References within files — String mappings also apply to strings within files, even if they 

are packaged within the XAR (such as a CSAR package). You need to be careful in raw 

string replacements to qualify your search string, and to avoid mapping key words, fixed 

namespaces, and related artifacts by string replacement. This feature is most useful for 

replacing URLs and references. For example, the following line might be for mapping 

references to targets used in the test environment: 

 



Whereas the same line in the production map might be: 

 

Constraining references to a specified file — You can limit a string replacement to a 

specific file by adding the artifactName attribute, as shown for Readme.txt: 

 

Phases of tailoring — String replacement can be applied in the tailoring rules which 

propagate to map file. The map files can be extended or further edited. You could either: 

● Do general changes in a general tailoring file—such as replacing 

sonicfs:///workspace/ with sonicfs:///com.myCorp/—and refine the projectspecific 

mappings in the map file for each target domain. 

● Do detailed changes in project-specific tailoring files so that map files can focus on 

finer tuning—such as the routings and quality of service—for each target domain. 

Adding Property Mapping Rules 

You can append a PropertyRules section at the end of the tailoring rules file to enable 

mapping the value of a specific property name to your preferred value. For example: 

 

 


Constraining property mapping to a specified file — You can limit property value 

replacement to a specific .properties or .props file by adding the artifactName attribute, 

as shown for ESBToREST.properties: 

 

 

 

 

 

Using StringReplace and PropertyReplace Content Change Rules 

The content change rules, StringReplaceMaps and PropertyReplaceMaps, are closely 

related. The following sections contain information about using both types. 

Rule Processing 

When you apply a map, its content change rules are processed as follows: 

1. PropertyReplaceMaps are processed before StringReplaceMaps and are checked for 

named rules and generic rules. 

■ If both a named rule and a generic rule exist, and both affect the same property, 

the named rule takes precedence over the generic rule. Best practice is to make 

sure that a named property file contains only one instance of a named property, 

because multiple instances may cause unpredictable results. 

■ If multiple generic rules exist, they are processed in a top-down manner. If 

multiple generic rules affect the same property, the last rule found in the map (that 

is, the rule nearest to the bottom) takes precedence. Best practice is to have only 

one generic rule. 

■ Generic rules extend to all properties files in the XAR and any component 

packages. Best practice is to use only named properties files, unless you are 

comfortable with changing properties globally. 

2. After all PropertyReplaceMaps are completed, StringReplaceMaps are processed. 



■ StringReplaceMaps are checked to determine the order of rules (specified with the 

order attribute) and then processed in the specified order. Unordered rules are 

processed after ordered rules. 

■ You can add an artifactName property to a StringReplaceMap to constrain its 

scope to the named file. But the rule is still processed in the stated order. 

■ If there are multiple unordered StringReplaceMaps, they are processed in a topdown 

manner. Best practice is to use only ordered rules, because multiple rules 

with no specific order may cause indeterminate results. 

Creating Properties Files 

It is good practice to make additional copies of properties files in preparation for tailoring. 

For example, copying ESBToREST.properties to ESBToREST_test.properties and 

ESBToREST_production.properties in SonicFS makes tailoring a bit easier. The alternative 

would be to extract the properties file from the XAR, make a named copy, and then add 

them back in to the XAR. 

This information was added to the “Mapping ESB Artifacts to Target Domains” chapter 

of the Progress Sonic ESB Deployment Guide. 

Improved Documentation: When mapping ESB artifacts always 

replace the name “workspace” 

This information was added to the Adjusting Tailoring Rules to Apply When Creating Map 

Files section of the “Mapping ESB Artifacts to Target Domains” chapter of the Progress 

Sonic ESB Deployment Guide at 8.0 SP 1. 

While you can revise the string replacement of sonicfs: path references from workspace 

to no name or any specified name, you should never leave the name workspace in a 

deployment configuration as it might trigger behaviors not intended for deployment 

environments. 

This information was added to the Adjusting Tailoring Rules to Apply When Creating Map 

Files section of the “Mapping ESB Artifacts to Target Domains” chapter of the Progress 

Sonic ESB Deployment Guide at 8.0 SP 1. 

The container caches a new copy of a file for each invocation of the service if a required 

file is located in the sonicfs:///workspace directory. This is by design, because the 

workspace directory is only intended for development. To stop the container from caching 

a new copy of a file for each invocation of the service, move the file outside of the 

workspace directory within the Directory Service storage, e.g. sonicfs:///MyFolder/. 


Improved Documentation: Dispatch Service 


The Dispatch service documentation was improved at 8.0 SP 1 as follows: 

Using a Dispatch service 

When you model an ESB process, you can use a Dispatch service to dispatch messages to 

ESB endpoints, ESB services, ESB processes, or sonic or jndi addresses. A jndi address 

can further resolve to a JMS destination. (See Format of the lookup name in Progress 

Sonic 8.0 SP1 Developer's Tools.) 

When you dispatch a message, it is delivered outside of the current process context—that 

is, the dispatched message contains no process context information. So when you invoke 

an ESB service (or ESB process) using a Dispatch step, the ESB framework does not 

override the invoked service's (or process's) exit endpoints. 

The Dispatch service can dispatch messages in either a one-way pattern or in a 

request/reply pattern. If you want to use the request/reply type pattern, be sure that the 

ESB service or ESB process receiving the request has one of its exit endpoints set to 

REPLY_TO; otherwise, the response message cannot be successfully returned to your calling 

ESB process. 

You can indirectly dispatch a message to a JMS destination by dispatching the message 

to an ESB endpoint that resolves to the JMS destination or by dispatching to a jndi 

address that resolves to a JMS destination. However, if you dispatch a message to an ESB 

endpoint as part of a request/reply type message exchange, keep in mind that an ESB 

endpoint, unlike an ESB service or ESB process, has no configured exit endpoints—so 

the reply must be handled through the JMS layer, via the JMSReplyTo property. This is also 

true of a JMS destination resolved from a jndi lookup. If the JMS application receiving 

the request does not reply within the Dispatch service's configured timeout interval, the 

invocation results in a rejected message (see fault in Progress Sonic Developer's Guide). 

The Dispatch service supports message mapping. (See Message Mapping in Progress 

Sonic Developer's Guide.) 

Specifying Properties for a Dispatch Service 

You specify properties for a Dispatch service in the Runtime Parameters section of the 

Service tab. You can use a variable (See the Progress Sonic Developer's Tools) to specify 

the value of the Destination, Message Exchange, and Reply Timeout properties. If you 



are using a variable to specify the value, you must click the checkbox in the table cell 

between the Name and Value columns before editing the Value field directly. 

Property Required Description 

Destination Yes Destination to which the message is dispatched—either 

an ESB endpoint, ESB service, ESB process, sonic 

address, or jndi address. A jndi address can further 

resolve to a JMS destination. 

ESB Quality 

of Service 

Message 

Exchange 

Reply 

Timeout 

No Quality of Service to use for the dispatched message. 

Valid values are: Best Effort, At Least Once, and 

Exactly Once. Default is Best Effort. 

Yes Message exchange pattern for the dispatched message. Valid 

values are: One Way and Request/Reply. Default is One 

Way. In Request/Reply mode, if the Dispatch service uses an 

ESB process or ESB service address, the Dispatch service 

gets the entry endpoint of the ESB process or ESB service and 

then sends a message by setting a JMSReplyTo header to a 

temporary destination where it waits for the response. 

Therefore, the Dispatch service imposes the following 

restrictions on the ESB services and processes that can be 

invoked in Request/Reply mode: First, the ESB service or 

ESB process should be configured with an entry endpoint. 

Second, at least one of the exit endpoints should be set to 

REPLY_TO. And third, the fault and RME destinations should 

also be REPLY_TO if you want the faults and rejected messages 

to be returned to the Dispatch service 

No Timeout value, in seconds, to wait for the response; applies 

only to request/reply message exchanges. Default is 30 

seconds. If the response is not returned in the timeout 

interval, the failed dispatch results in a rejected message. 

Dispatch service example 

Sonic Workbench provides a sample demonstrating the Dispatch service. The sample is 

contained in the Samples.ESB 

The sample shows how the Dispatch service can be used from within an ESB process to 

make a one-way or request-reply invocation to an ESB address. The dispatch step also has 



support for message mapping that allows you to customize the request and reply (in case 

of request/reply) messages. 

Support for Variables in the Dispatch Service 

You can specify the value of the Destination, Message Exchange, and Reply Timeout 

properties. The value of these properties can be obtained from the incoming message or 

from a property file, container deployment property, or system property. 

Support for sonic and JNDI URI in the Dispatch Service 

The target for a Dispatch step can be specified in a Destination property as a sonic or 

JNDI URL, in addition to an ESB address. 

This improved documentation has been added to the Sonic Workbench online help in the 

Workbench and in its PDF version, Working with Built-in ESB Services. 



Improved Fault Handling within ESB Processes 

Sonic ESB provides a built-in scheme for handling faults (and RME messages) using 

process modeling constructs. This scheme enables you to handle faults and RME 

messages directly in ESB processes, without modifying any underlying service code, in a 

manner that is analogous to how Java handles exceptions. 

This functionality is documented under “Fault Handling overview” in the “Progress Sonic 

ESB Developer’s Guide” section of the Sonic Workbench online help. 


Message Mapping 


This feature provides an option for Service Type developers to create services that see 

only a partial view of the ESP Process inflight messages. This gives ESB process 

modelers greater runtime flexibility and control over Service steps. 

This feature enables an ESB process developer to determine how an ESB process can take 

only a subset of the information in the inflight message and pass it to the inbox of the 

service (and take the service outbox XQMessage and merge it with the inflight process 

message): 

You can enable message mapping for existing service types and for custom Java service 

types. When you define a message mapping rule, you can also define namespaces, if 

needed, enabling you to specify XML prefixes in XPath expressions. This functionality is 

documented under “Message mapping” in the “Progress Sonic ESB Developer’s Guide” 

section of the Sonic Workbench online help. 



Fault Handling with Sonic Interceptors 

Sonic interceptors can augment Sonic's built-in fault handling. Sonic interceptors are an 

extension of Spring interceptors. Although Sonic interceptors can do more than just 

augment fault handling, they were added in 8.0 specifically for this purpose: 

This functionality is documented under “Using Sonic interceptors for fault handling” in 

the “Progress Sonic ESB Developer’s Guide” section of the Sonic Workbench online help. 


Service Configuration Editor 


The Service Configuration Editor enables you to edit service configurations directly in the 

Sonic Workbench, without using the Sonic Management Console (SMC): 

This editor is documented under “Service Configuration editor” in the “Progress Sonic 

Editors” section of the Sonic Workbench online help. 

Sonic Connect Projects 

A Sonic Connect development project allows you to work with Web services and 

RESTful Web services. Sonic Connect projects are documented under “Sonic Connect 

Integrated editor” in the “Progress Sonic Editors” section of the Sonic Workbench online 

help. 



Sonic Connect Editor 

The Sonic Connect editor provides the tools needed to create and modify Sonic Connect 

services. Some of the Web service tools are derived from the Eclipse WTP project. 

This editor is documented under “Sonic Connect Integrated editor” in the “Progress Sonic 



Dispatch Service Step 


A Dispatch Service step enables you to invoke an ESB address without passing along 

process context information. For example, you might invoke an ESB endpoint that 

resolves to a JMS topic or queue. 

This step is documented under the “Progress Sonic Editors” section and the “Progress 

Sonic ESB Developer’s Guide” section of the Sonic Workbench online help. 



Flow Termination Steps 

Several new flow termination steps replace the End step. Many of these steps are used 

with Fault Handling: 

Step 

Type Description 

Exit Explicitly exits the process. 

Fault Generates a fault and addresses a 

message to the fault destination. 

Reject Rejects a message and addresses a 

message to the RME. 

Rethrow Rethrows the underlying RME or fault, 

causing further escalation of the fault. 

Resubmit Resubmits the message to the ESB 

process or process step that originated 

the RME or fault message. 

Terminate Terminates the execution of the 

process. 

Step Graphic in ESB Process 

Editor 

These steps are documented under “ESB Process Editor” in the “Progress Sonic Editors” 

section and under “Fault Handling overview” in the “Progress Sonic ESB Developer’s 

Guide” section of the Sonic Workbench online help. 


Sonic Deployment Manager features in 8.0.x 


The following feature was introduced in Sonic Deployment Manager in 8.0 SP 1: 

● “Message Compression Tuning Elements” 

Message Compression Tuning Elements 

The Tuning.xsd supports message compression in ConnectionFactoryParameters 

parameter: 

● Enable Compression — When selected, requires connections that use this connection 

factory to perform message compression before sending messages, and requires the 

broker to deliver compressed messages to connections that use this connection 

factory. The setting could be overridden by the client. 

● Custom Compression Factory — Specifies the custom class that defines message 

compression and decompression. 

● See “Message Compression” on page 77 for more information about this new feature. 

Revised Documentation in 8.0 SP 1 

SDM documentation has been enhanced to provide better information as follows: 

● “Enhanced Remote Resources Chapter” on page 128 

● “Document How to Create an SDM Audit File” on page 128 

● “Video Demonstration of Centralized Install and Provisioning” on page 128 

Enhanced Remote Resources Chapter 

Examples of copy operations let you demonstrate copying resources to the local Domain 

Manager machine and to a remote machine 

The local resources section is recast to position it properly in the new SDM paradigm. 

Document How to Create an SDM Audit File 

The SDM in 8.0 introduced the ability to create a record of actions taken on hosts. The 

new commandline parameter, audit_file, was not documented at that time. The feature 

is now described in the Progress Sonic Deployment Manager User’s Guide as follows: 

● audit_file — When specified with an arbitrary file name, logs the actions taken on 

hosts. Reuse of the log in subsequent runs appends new entries to an existing audit 



file. For example, specifying audit_file=c:\basic.audit and then running a 

cleanDomain command and, later, an updateDomain command for the Basic sample 

would produce an audit file that looks like this: 

date 17:18:04,Administrator,localhost,[default],/Containers/ctData2,SUCCESS,setupContainer, 

date 17:18:04,Administrator,localhost,[default],/Containers/ctManagement,SUCCESS,setupContainer, 



Configuring Domains Using Centralized Installation 

As the SDM runs on only the Domain Manager system, any tasks needed on remote 

systems require tools that can perform tasks on the remote system. 

Sonic 8.0 provides two functions that enable the SDM to perform tasks on remote 

systems: 

● Sonic Container Launcher. — Establishes Sonic on distributed systems, and enables 

setting up containers with HostManager objects. See the “Using Progress Sonic 

Launcher Installer” and “Setting Up Containers” chapters of the Progress Sonic 

Installation and Upgrade Guide for more information. 

● Host Manager framework component — Provides a mechanism for accessing remote 

hosts from the Management Console and the SDM. See the “Configuring Containers” 

and “Managing Containers and Collections” chapters of the Progress SonicMQ 


When the Sonic Container Launcher runs on a remote system, it does not require any 

license keys. It establishes the Sonic home, the JVM, and the container working 

directories. See the “Using Progress Sonic Launcher Installer” and “Setting Up 

Containers” chapters of the Progress Sonic Installation and Upgrade Guide for more 

information. 

Topology file for Environments and Logical Hosts 

Sonic’s centralized installation functionality lets you define the physical machines in a 

deployment infrastructure so that the definitions of logical machines can be mapped to the 

physical machines of a specified environments. 

The fundamental goal of the Sonic Deployment Manager is to define interactions of 

components that are independent of specific IT assets. This chapter shows how machines 

are mapped to a model in the model’s Topology.xml file. 



The concept of logical hosts in a model allows a configuration or runtime component to 

be bound to zero, one or more logical hosts. The mapping to physical hosts was implicit 

in Version 7 because SDM had to run in each participating machine, declaring its list of 

hosts to be mapped (or defaulting to all) to that installation/ 

Version 8 introduces Topology.xml, the file in a model that structures the environment and 

host information, and then leverages the Sonic centralized installation function to bind the 

configurations, components, and resources of a logical host to a physical host managed in 

the domain. Thus, the SDM runs on the same host as the domain it manages. 

Remote Resources 

Sonic’s SDM has always supported local resources—you could define copy tasks in a 

model’s Resource.xml file, and removals or deletions in a model’s Deletes.xml file’s 

Resources segment. Those were local resources because the nature of the SDM was that 

it had to run to each machine that was a host. 

Version 8 introduces semantics for remote resources that deprecate the use of local 

resources to provide the ability of the SDM running on the Domain Manager system to 

perform resource functions on remote systems that copy files to remote systems, delete 

files on remote systems, and execute tasks on remote systems. 

● Copy operations can copy a file from an SDM accessible folder to an SDM defined 

remote machine, and copy a folder and all its content from an SDM accessible folder 

to an SDM defined remote machine. 

● Delete operations can delete a file from an SDM defined remote machine, and delete 

an folder from an SDM defined remote machine 

● Exec operations are a set of actions that copy a specified Ant build file to a remote 

target, and then run the build. The deployment of Ant to the remote machine is 

handled by the execute operation. 

New Schema Elements and Samples of Features 

SDM 8.0 provides several schema enhancements that enable modelling new features— 

message grouping, config-time setting of metrics/alerts, and IPV6—and existing Sonic 

functions previously not supported in the SDM—management permissions, backup 

containers, container collections, and JMS Administered Objects in the Domain 

Manager’s JNDI store. 

The following sections describe these features and patterns from those that provide 

sample models. 



Management Permissions 

The SDM can set the complex of permission hierarchies. When retained strictly at the 

SDM model on the Domain Manager, setting and revising permissions is greatly 

simplified and more easily reviewed than item-by-item maintenance in the management 

console. The following is an excerpt from the Permission sample’s Model.xml file: 

 

 

 

central 

 

 

/ 

Administrators 

Fullcontrol 

 

 

/ 

Monitors 

monitorsRole 

 

 

 

ESBContainer and Backup Management Containers 

ESB containers can take advantage of the ability of management containers to provide a 

fault-tolerance mechanism. The sample model ESBContainers demonstrates their 

configuration for ESB, but the techniques apply to Event Monitors and Activation 

Daemons as well. The following is an excerpt from the Model.xml of the sample: 

 

**** 

 

 

 

esbContainer1 

ctESB 

ctESBBAK 

 

true 

 

The excerpt uses the Clone tag, which indicates that the same ESB container should be 

used in the backup container. The primary container will be created first, as a regular (non 

fault tolerant) container. During subsequent processing, the creation of the backup 

container will result in a modification of the primary container's configuration so that the 

primary becomes a fault tolerant container. 



Tuning parameters can be added to a fault-tolerant management container, as shown: 

 

true 

... 

 

10 

10 

false 

 

 

An Actional interceptor on an ESB container can be enabled through SDM tuning 

parameters, as shown: 

 

 

true 

true 

 

 

A sample model is provided. 

Configuration Time Metrics and Alerts 

SDM model can configure metrics and alerts for containers and their components. This 

supports the new feature in SonicMQ that provides for definition of persistent settings for 



metrics and alerts at configuration-time as well as overrides at runtime. The parameters 

might create a pattern like this in a model’s Tuning.xml file: 

 

 

brData1 

 

 

 

queue.messages.Count 

 

 

100 

 

 

 

 

 

queue.messages.Count.SampleQ1 

 

 

50 

 

 

 

 

 

 

 

 

esbContainer1 

 

 

 

esb.service.messages.AverageProcessingTime 

 

 

 

 

 

 

 

 

 

broker.connections.Count 

queue.messages.Count 

queue.messages.MaxDepth 

 

60 

 

 

Message Grouping 

The SDM provides elements for the queue settings that establish Message Grouping 

behaviors on a queue. Message grouping, introduced in Sonic 8.0, involves the message 



producers setting a property on messages that a broker will manage by allocating 

messages to consumers on virtual exclusive queues based on the property value. The 

message grouping settings are all in a model’s Tuning file, as shown is this excerpt from 

the MessageGrouping sample model: 

 

Alternate Group Name2 

true 

3000 

22 

7200000 

 

JNDI Support 

SDM supports creation JMS Administered Objects, allowing you to create queues, topic, 

multitopics, connections, and XQ connections in the Domain Manager’s JNDI store. 

A sample model is provided. An excerpt of that model follows: 

 

 

SampleCF 

ConnectionFactoryParams 

jms/sonic 

mqClient 

mqClient 

 

tcp://localhost:2506,tcp://localhost:2507 

 

 

 

Container Collections 

The ContainerCollection element defines container collections in the form: 

 

myCollection 

 

ctESb1 

ctBrData1 

ctBrData2 

 

 

A sample model is provided. 



Enhanced Remote Resources Chapter 

Examples of copy operations let you demonstrate copying resources to the local Domain 

Manager machine and to a remote machine 

The local resources section is recast to position it properly in the new SDM paradigm. 

Document How to Create an SDM Audit File 

The SDM in 8.0 introduced the ability to create a record of actions taken on hosts. The 

new commandline parameter, audit_file, was not documented at that time. The feature 

is now described in the Progress Sonic Deployment Manager User’s Guide as follows: 

● audit_file — When specified with an arbitrary file name, logs the actions taken on 

hosts. Reuse of the log in subsequent runs appends new entries to an existing audit 

file. For example, specifying audit_file=c:\basic.audit and then running a 

cleanDomain command and, later, an updateDomain command for the Basic sample 

would produce an audit file that looks like this: 





Video Demonstration of Centralized Install and Provisioning 

This set of video presentations, How SDM Models Configure Remote Machines for 

Provisioning, detail how an installed Domain Manager and three remote Launcher 

installations are provisioned through the Sonic Deployment Manager’s 

HotHotMessagingCluster model to establish replicated brokers on two of the machines 


Chapter 4 What was new and changed in 7.5 and 7.6 

releases 

This chapter describes new and enhanced functionality in the Progress Sonic products in 

the following sections: 

● “SonicMQ and Managememt Framework features in Version 7” 

● “Sonic ESB and Workbench features in Version 7” 

This chapter describes Sonic functionality in the latest Version 7 releases that apply since 

the oldest supported release, 7.5. If your installations are not at the last Version 7 release, 

7.6 SP 2, review “What was new and changed in 7.5 and 7.6 releases” on page 129 to see 

the changes in that were implemented in newer Version 7 releases. 

The required upgrade procedures for Sonic installations to advance from Version 7 

directly to Sonic 8.5 are detailed in “Upgrading from Version 7 to Sonic 8.5” on page 95. 

Note While there were changes in installers and the Sonic Deployment Manager in Version 7 

releases, those changes are not relevant when transitioning to Sonic 8.5. See Chapter 4, 

“Upgrading from Version 7 to Sonic 8.5” for more information. 


Chapter 4: What was new and changed in 7.5 and 7.6 releases 

SonicMQ and Managememt Framework features in 

Version 7 

The features added and changed for SonicMQ and the Managhement Framework in 

supported Version 7 releases are categorixed by release: 

● “New and Revised SonicMQ Features in 7.6” on page 130 

● “New SonicMQ Feature in 7.5.2” on page 132 

New and Revised SonicMQ Features in 7.6 

The following features were new in SonicMQ 7.6: 

● Actional integration — Progress Actional instrumentation is now available to 

SonicMQ brokers. This enables tracking the flow of a message from a publishing 

client through one or more brokers and ultimately to the subscribing client in a 

deployment. Features on a broker’s new Monitoring tab enable the instrumentation. 

This feature requires Progress Actional software products to provide visibility, 

control, and enforcement of deployed assets. 

See the new “Configure Broker Monitoring Properties” section of the “Configuring 

SonicMQ Brokers” chapter of the Progress SonicMQ Configuration and 

Management Guide for more information. 

● Improved producer throughput — Message producer throughput performance for 

non-transacted sessions can be improved significantly by setting asynchronous 

delivery mode on the producer’s connection. A new 

NON_PERSISTENT_REPLICATED_ASYNC delivery mode has been introduced. 

NON_PERSISTENT_ASYNC and NON_PERSISTENT_SYNC delivery modes are deprecated in 

favor of the ConnectionFactory level settings. However, if used by existing 

applications they are supported and behave as expected. 

See the “Asynchronous Message Delivery” section of the “SonicMQ Connections” 

chapter of the Progress SonicMQ Application Programming Guide for details. 

● Container Logging Enhancements 

■ Remote Viewing of a Log — A snapshot of a running container’s log can be 

accessed by a remote administrator through the SMC. The file can be searched 

and saved on the administrator’s system. 

■ Central log — A container can be configured to send its essential log entries to 

the Agent Manager’s system where the entry is appended to the central log. The 

entire domain can be forced to send entries to the central log. 


SonicMQ and Managememt Framework features in Version 7 

■ Archiving Logs at Thresholds — The local container log and the central both 

provide thresholds for archiving the current log and clearing the current log. 

See the revised “Container Logging” section in the “Managing Containers and 

Collections” chapter of the Progress SonicMQ Configuration and Management 

Guide for more information. 

● Routing node can be set and enforced at cluster level — In order to ensure that all 

broker members of a cluster are set to the same routing node name, the cluster’s node 

name is set on the cluster, and overrides the one set on each individual member broker. 

● Setting JMSXUserID — Previously, the option to have a security-enabled broker add 

the user name to each message in the header property JMSXUserID was an advanced 

broker property. It is now a checkbox on the General tab of a broker and its entry as 

an advanced property is invalid. Upgrade procedures will transfer an existing 

advanced property set to true to selection of the checkbox. 

● Limiting connection sessions and temporary queues — Two new advanced broker 

properties, CONNECTION_TUNING_PARAMETERS.MAX_TEMPORARY_QUEUES_PER_SESSION and 

CONNECTION_TUNING_PARAMETERS.MAX_SESSIONS_PER_CONNECTION, have been 

introduced. 

● DS Replication Connection Timeout — A JVM system property lets you tune how 

long Directory Service instances wait for the replication peer before continuing with 

the startup sequence standalone. 

See the note in the “Configuring Replication Connections for Directory Service 

Peers” section of the “Configuring Framework Components” chapter of the Progress 

SonicMQ Configuration and Management Guide for more information. 

● JCA Adapter for WebLogic — The Sonic Resource Adapter enables a WebLogic 

application server to integrate with SonicMQ. The Sonic Resource Adapter conforms 

to the J2EE Connector Architecture Version 1.5 Specification and works with 

WebLogic Application Server 9.2. 

● Memory Sizing Spreadsheets — Documentation includes sizing worksheets to help 

you estimate memory required for a broker and its destinations (queue and topic). 

Changes and improvements in this release might require actions to adjust existing 

configurations and applications.The following features changed for SonicMQ V7.6: 

● Container Logging Changes — Where earlier Sonic versions specified the explicit 

path to the log file, the archiving mechanism introduced in 7.6 requires you to define 

a log folder which will store the current log and its archives. The process is automatic 

on upgrade, renaming the existing domain_name.container_name.log file to 

domain_name.container_name.log.old, creating a folder named 



domain_name.container_name.log that contains a file named 

domain_name.container_name.log. 

● Windows Services No Longer Requires -Xrs— A container launched as a Windows 

Service now uses native code to ignore user logoff events so the Java -Xrs option 

should no longer be specified, thereby allowing the JVM to receive Ctrl-Break 

signals to initiate thread dumps. 

● Changes to Some Logger Metric Names — Two metrics names were modified to 

improve consistent naming across the products. The changed metrics names are: 

■ logger.rate.metrics is now logger.metrics.LoggedPerMinute 

■ logger.rate.notifications is now logger.notifications.LoggedPerMinute 

● JNDI SPI — Some usages such as application servers might only accept standard 

environment properties. In those circumstances, you can add Sonic-specific 

properties as parameters of the PROVIDER_URL, as shown: 

Code Sample 2. Using Sonic JNDI SPI with URL Parameters 

Hashtable env = new Hashtable(); 

env.put(Context.INITIAL_CONTEXT_FACTORY, 

"com.sonicsw.jndi.mfcontext.MFContextFactory"); 

env.put(Context.PROVIDER_URL, 

“tcp://localhost:2506?domain=Domain1&idleTimeout=60000"); 

env.put(Context.SECURITY_PRINCIPAL, "Administrator"); 

env.put(Context.SECURITY_CREDENTIALS, "Administrator"); 

Context ctx = new InitialContext(env); 

.. 

Queue queue = (Queue)ctx.lookup(“queues/Q1”); 

.. 

New SonicMQ Feature in 7.5.2 

Subscriber Visibility Through the Runtime Management API 

SonicMQ broker monitoring provides a new feature in the Runtime Management API that 

provides information about message backlogs of running nondurable subscriber 

applications. 

This enhancement was introduced to assist large deployments with identification of slow 

non-durable subscribers causing flow control issues. The feature gives additional 

visibility into resource usage of subscribers; specifically, identification of which 

subscribers are consuming the most broker memory and data store resources. 

See the Progress SonicMQ Administrative Programming Guide chapter “Using the 

Runtime API for the Sonic Management Environment” for more information. 


Sonic ESB and Workbench features in Version 7 


Progress Sonic ESB and Sonic Workbench included the following enhancements in 7.6.2: 

● “Payload capture on the first part of a multipart message” on page 134 

● “Enhanced Documentation: ESB binding when creating WSDL” on page 134 

Progress Sonic ESB and Sonic Workbench included the following enhancements in 7.6.1: 

● “Support for Actional Server Trust Zones Introduced” on page 135 

● “ESB Service Type Requires a Properties File” on page 135 

● “Setting an ExceptionListener on an ESB Container JMS Connection” on page 135 

● “Registering and Unregistering Transient Endpoints as Entry Endpoints” on page 135 

Progress Sonic ESB and Sonic Workbench included the following enhancements in 7.6: 

● “Scenario Improvements” on page 136 

● “Run/Debug Improvements” on page 136 

● “ESB Process Editor” on page 137 

● “ESBWS Editor” on page 146 

● “Custom Java Service Type Editor” on page 147 

● “Progress Sonic BPEL Server Enhancements” on page 147 

● “Containers View” on page 148 

● “Refactoring” on page 148 

● “Message Sender View and Message Listener View” on page 149 

● “Added two tutorials; Dropped Supply Chain sample” on page 149 

● “Enhancements to the File Handling Services” on page 150 

● “Enhanced the Split and Join services” on page 151 

● “DB Navigator” on page 152 

● “ESB Configuration API,” and “Miscellaneous” on page 152 

The Sonic ESB and Sonic Workbench included the following enhancements in 7.5.1: 

● “Web Service Invocation Editor” on page 153 

● “ESB Process Editor” on page 154 

● “Enhanced Scenarios” on page 155 

● “Enhanced Container Management” on page 155 

● “Java Service Type Editor” on page 156 

● “Deploy Directory and XAR Upload” on page 156 



● “Enhanced XPath Helper” on page 156 

● “Other Enhancements” on page 156 

Progress Sonic ESB and Sonic Workbench included the following features in 7.5: 

● “Progress Sonic BPEL Server” 

● “Advanced Web Services Interoperability” 

● “Enhancements in Sonic Workbench” 

● “Performance Improvements” 

● “Leverages Progress DataXtend Semantic Integrator” 

● “Integrates Progress Actional for SOA Operations” 

Payload capture on the first part of a multipart message 

SNC00070773 — Sonic ESB supports payload capture for the first part of the message 

and that too if the Content type is text/xml or application/xml. 

A new feature in the Sonic ESB Actional interceptor is support for payload capture for the 

first part of a multipart message with user defined MIME types. The restriction still holds 

that the first part should contain a string or a JMS TextMessage. 

To add custom MIME types, they are added to the Global configuration in the Directory 

Service so that they apply to all ESB containers in the domain. In the ESBAdmin tool, use 

the following command: 

set global PayloadCaptureMimeTypes "text/plain,application/custom-text" 

and replace the placeholder values in the last argument with a comma-separated list of 

MIME types that you want to include for payload capture. 

To reset the configuration (that is, to remove all custom MIME types), use the following 

ESBAdmin command: 

set global PayloadCaptureMimeTypes " " 

Enhanced Documentation: ESB binding when creating WSDL 

SNC00070475 — Information on ESB binding when creating WSDL. In Workbench 

online help, the Create WSDL task was not clear about ESB binding. The following note 

has been added to the online help: 

If you are creating a WSDL for an ESB process, either by clicking the 

To generate the WSDL for this Interface link on the ESB Process editor's Interface page, 

or by wrapping the ESB process as a Web service, you must choose a Binding Type (SOAP 

or ESB). If you choose ESB as the Binding Type, the interface of the ESB process (as shown 



on the Interface page) must conform to ESB binding rules: that is, each Parameter in the 

interface must map one-to-one to a message part, and the name of each Parameter must 

match the name of its corresponding message part. 

Support for Actional Server Trust Zones Introduced 

You can use Progress Sonic ESB 8.0 with Progress Actional to implement trust zones, 

which provide an additional layer of security in a SOA environment. In Sonic ESB, trust 

zones are only supported for SOAP messages over HTTP. 

See Chapter 12 of the Progress Sonic ESB Configuration and Management Guide, “Using 

Actional Trust Zones in Sonic ESB,” for more information. 

ESB Service Type Requires a Properties File 

In prior releases, an ESB service type without a corresponding properties file could be 

configured in the ESB Configured Objects section of the Sonic Management Console. 

As of V7.6, the service type properties file is required for the service initialization 

parameters to be shown properly in the SMC. Service type properties files are stored in a 

domain’s Directory Service Sonic file system on the path: 

/System/SonicESB/properties/servicetypes 

Setting an ExceptionListener on an ESB Container JMS 

Connection 

Sonic ESB supports setExceptionListener on the ESB container JMSConnection wrapper. 

This method, setExceptionListener, supports the chaining in of custom JMS 

ExceptionListeners. 

Registering and Unregistering Transient Endpoints as Entry 

Endpoints 

ESB services can perform registration and un-registration of both configured and 

transient endpoints as entry endpoints. 



Scenario Improvements 

In the Progress Sonic Workbench, several editors now provide a Scenarios page, from 

which you can create, modify, and run scenarios. You can drag and drop input files onto 

the Scenarios page from the Navigator view. 

Scenarios can be integrated with the Eclipse launch configuration, supporting hot-key 

combinations like those provided by the Java Development tools, and providing the ability 

to re-launch the last configuration launched: 

Run/Debug Improvements 

ESB processes are validated under the following conditions: 

● When the option to build automatically is enabled, the ESB process is validated when 

the process is saved. 

● When you run a scenario for an ESB process, the ESB Process editor validates the 

process. 

The validation determines whether there are any problems in the services and 

subprocesses used by the process steps, and checks for common errors that might lead to 

unexpected results when you run or debug an ESB process. This functionality is 

documented under “Validating an ESB process” in the “ESB Editors” section of the Sonic 

Workbench online help. 


ESB Process Editor 

Support for New Services 


● SOAP Unwrap Step: The ESB Process editor provides support for generic unwrap 

SOAP steps. When implementing a web service, you can now use an unwrap SOAP 

step in an ESB process (which implicitly unwraps the SOAP) instead of an ESBWS 

file (which explicitly unwraps the SOAP. An implicit unwrap SOAP step is embedded 

inline in the ESB process and requires no additional artifacts. 

● New terminate step and branch to terminate the current execution of the process at 

that step (fanout/decision/main branch). See the “Terminating a branch or an ESB 

process” topic in the “ESB Process editor” help under “ESB editors” in the “Progress 

Sonic Editors” section of the Sonic Workbench online help. 

● The Prototype Service (dev.Prototype) enables you to create and quickly run an ESB 

process before creating all the actual service steps. You can improve the simulation 

by dragging .xml or .esbmsg files onto the process, which add a Prototype service and 

this service will output the same document when running. When a generic service 

step is added to an ESB process, it is a Prototype service by default. Similar to the 

dev.Prototype service, the dev.nullProcess prototype ESB process is provided for 

quick simulations. This process is assigned by default when adding a Process step. 

See the “Using a Prototype service” and “Using a prototype process” topics in the 

“ESB Process editor” help under “ESB editors” in the “Progress Sonic Editors” 




● Progress Sonic JMS service for WebSphere MQ: This service includes the WMQ 

JMS Queue Listener On-ramp and WMQ JMS Queue Sender Off-ramp services. 

These services provide connectivity between Sonic ESB and WebSphere MQ JMS 

messaging. This integration enables developers to exchange data between Sonic ESB 

and WebSphere MQ. The service is documented under “JMS service for WebSphere 

MQ” in the “Progress Sonic ESB Services” section of Sonic Workbench online help. 

Palette re-organization 

● New Palette options to show icons only and use large icons. 

● A new group, Favorites, where you can manually add or remove commonly used 

services and process templates. 

● Capability to hide/show the Recent services group or Favorites group. 

See the “Customizing the Palette” and “Customizing the Favorites section of the Palette” 

topics in the “ESB Process editor” help under “ESB editors” in the “Progress Sonic 


Process Templates 

New templates based on best practices include: 

Name Used in Enterprise Integration Pattern 

Split XML on XPath Sample.B2RT Splitter 

Operation Router Sample.RIA Content-Based Router! 

Drop File in Directory Sample.B2RT Event Driven Consumer 

VETO Sample.B2RT n/a 

See the “Using process templates” topic in the “ESB Process editor” help under “ESB 

editors” in the “Progress Sonic Editors” section of the Sonic Workbench online help. 

Template Parameterization 

While creating a template, you can mark resources in the ESB process template file as 

template parameters. These parameterized resources are copied to the workspace from the 

specified path while dropping the template. See the “Parameterizing resources for process 

templates” topic in the “ESB Process editor” help under “ESB editors” in the “Progress 



XCBR/CBR Improvements 


● Instead of an empty branch, a new branch is created with a prototype service step. See 

the “Adding a branch to an ESB process” topic in the “ESB Process editor” help under 

“ESB editors” in the “Progress Sonic Editors” section of the Sonic Workbench online 

help. 

● Improved validation of XCBR and CBR steps to detect incorrect step names that do 

not match the step-based rules. See the “Validating an ESB process” topic in the “ESB 

Process editor” help under “ESB editors” in the “Progress Sonic Editors” section of 

the Sonic Workbench online help. 

● Improved top-down creation of XCBR/CBR routing rules file from a decision step in 

the ESB Process editor. The new file is automatically populated with the correct stepbased 

routing rules with default value for the rule conditions. See the “Adding XPath 

routing rules” topic in the “XPath Routing Rules editor” help and the “Adding, 

editing, and deleting routing rule conditions” topic in the “Routing Rules editor” help. 

These topics are under “ESB editors” in the “Progress Sonic Editors” section of the 

Sonic Workbench online help. 



Split and Join Parallel service 

Split and Join Parallel service steps in the ESB Process editor show the called addresses 

to provide navigation to the subprocess via hypertext links. See the “Navigating to called 

addresses” topic in the “ESB Process editor” help under “ESB editors” in the “Progress 


Easy Navigation from the ESB Process Editor Process Page 

Improved navigation from steps in the ESB Process editor page to any primary file type 

via context menu options. See the “Navigating to files from ESB process steps” topic in 

the “ESB Process editor” help under “ESB editors” in the “Progress Sonic Editors” 




WSDL Drag and Drop: Inline Web Service Invocation 

You can add a web service invocation step to an ESB process by dragging a WSDL file 

from the Navigator view and dropping it onto the ESB process canvas. In response, the 

ESB Process editor creates an inline invocation script. An inline invocation script is 

simpler to use than an external Web Service Invocation file (.esbws) and requires no 

external artifacts. An inline script, however, is not reusable. Also, you must use an inline 

script to invoke services, whereas you can use a Web Service Invocation file to invoke and 

to implement services. 



Variable Substitution Support 

In the Service page of the ESB Process editor, you can use variable substitution for certain 

parameters, such as the WSDL Port Address parameter for web services and the 

Configuration Document parameter for File Services. The substitution can be for a 

properties file, a message header, or a deployment parameter: 

Validation 

Validating an ESB process with a nested subprocess shows any problems with the 

subprocess. 


Miscellaneous 

The context menu is enhanced for easy access to actions: 




The enhanced ESB process creation wizard allows you to create an ESB process with 

different options. See the “Specifying options to create an ESB process” topic in the “ESB 

Process editor” help under “ESB editors” in the “Progress Sonic Editors” section of the 


The layout in the Service editor pages (except for the Invocation services) has been 

changed to utilize the available space. 

The ESB Process editor provides a clearer message when failing to connect to the domain 

manager: 



The representation of the end of a decision is now consistent with the representation in the 

BPEL editor: 



ESBWS Editor 

The Mappings page layout has been changed to utilize available space. 


Custom Java Service Type Editor 


● Java Service Type Template Enhancements — XQServiceEx has become the 

standard interface for implementations of services due to its enhanced functionality. 

The tooling now by default generates a Java Service Type as an implementation of 

XQServiceEx. 

● ESB Classloading — Sonic ESB provides a flexible, built-in classloading scheme. 

This scheme enables you to exercise fine-grained control over Java classloading, if 

required by your application. This scheme also enables you to specify the classes 

required by a service type without reconfiguring its host ESB container or containers. 

With this scheme, you can be certain your ESB containers, ESB services, and ESB 

processes load the correct classes at runtime. 

● Service Lifecycle Control — Your ESB service code can explicitly control its own 

lifecycle and, to a limited extent, the lifecycle of its host ESB container. 

● Dynamic Endpoints — Your ESB service code can create and manipulate one or more 

dynamic endpoints — transient endpoints that, unlike configured endpoints, reside 

only in memory. Your service can use dynamic endpoints to provide secondary input 

and output channels, without changing the service configuration. After creating 

dynamic endpoints, your service code can use them just like pre-configured 

endpoints. 

● API Access to JMS Connections and Sessions — An ESB service can access its 

underlying JMS connection and session objects. By doing so, the service can both 

produce and consume messages at the JMS level instead of at the ESB level. 

Progress Sonic BPEL Server Enhancements 

● Consistent process look and feel with Itinerary Editor — The BPEL editor now 

provides consistency with the ESB Process editor for the start and end figures in a 

sequence, the color for connecting lines, and the appearance of decision figures. 

● BPEL Editor Usability Enhancements — Drag and drop support for ESBP file to add 

an invoke step. 

● Deployment Descriptor Editor Enhancements 

■ My Endpoints tab 

■ PartnerLink Property metadata 

● Other Enhancements 

■ Error marker is shown on the BPEL file icon in the navigator when it has errors. 

■ Creating ESBMSG from BPEL Scenario panel populates required headers. 



Containers View 

Refactoring 

● Keep the containers alive when Domain Manager started outside even after shutting 

down the Workbench, so that the Workbench gets connected faster when started next 

time. 

● Container view supports management of multiple ESB Containers deployed in a 

single MF Container. 

● Enable/Disable Actional Visualization for ESB Container. 

● Container view shows state (online, offline and error state) of individual services and 

processes and shows last error details in property dialog. 

● ESB Service/process is provided with the operations Start and Stop. 

● The ESB Process editor and Navigator view support searching for references of an 

ESB process used as a subprocess, an ESB address destination, or a routing 

destination and searching for references of ESB process step. They also support 

searching for content-based (CBR) and XPath content-based (XCBR) routing rules 

files used in an ESB process. This functionality is documented under “Searching for 

references of ESB processes and routing rules files” in the “Progress Sonic 

Workbench” section of the Sonic Workbench online help. 

● The ESB Process editor supports refactoring step name changes in routing rules files 

and ESB processes. Refactoring finds references of the changed steps in the current 

routing rules or ESB process files, and provides you the option of updating them with 

the new names. This functionality is documented under “Refactoring step name 

changes in routing rules files” and “Refactoring step name changes in ESB processes” 

in the “Progress Sonic Workbench” section of the Sonic Workbench online help. 

● The ESB Process editor and Navigator view support refactoring when ESB processes 

and routing rules files are moved. When you move an ESB process or routing rules 

file to a new location, you have the option of updating references of the changed 

location in ESB processes and routing rules. This functionality is documented under 

“Refactoring when ESB processes and CBR or XCBR files are moved” in the 

“Progress Sonic Workbench” section of the Sonic Workbench online help. 



● The ESB Process editor and Navigator view support refactoring when ESB processes 

and routing rules files are renamed. When you rename an ESB process or routing 

rules file, you have the option of updating references of the changed files in ESB 

processes and routing rules. This functionality is documented under “Refactoring 

when ESB processes and CBR or XCBR files are renamed” in the “Progress Sonic 


Message Sender View and Message Listener View 

Enhancements to the Message Sender and Listener views include: 

● "Resend Last Message" action to send the last sent message on a specific sender. 

● "Send Default Message" option to send the associated default message on a JMS 

Destination. 

● Multi-select in the "Message Listener" view to stop and start multiple listeners. 

These views are documented under “Sending and listening for ESB messages” in the 

“Progress Sonic Development and Debugging Tools” section of the Sonic Workbench 

online help. 

Added two tutorials; Dropped Supply Chain sample 

Changes and enhancements to the samples and tutorials include: 

● The Supply Chain sample was removed. 

● The Batch to Real-time tutorial provides step-by-step instructions to develop a sample 

application to processes batch purchase orders in real time. You will see how easy it 

is to use Sonic Workbench to prototype and implement an enterprise SOA 

application. This tutorial is documented under “Batch to Real-time tutorial” in the 

“Progress Sonic ESB Samples and Tutorials” section of the Sonic Workbench online 

help. To watch an online demo of the entire tutorial, open the documentation portal 

for the Progress Sonic ESB Product Family (from the Start menu, select Programs > 

Progress > Sonic 7.6 > Documentation) and click on the link to the multimedia 

demonstration for the Batch to Real-time tutorial. 

● The Remote Information Access tutorial walks you through the process of building 

an ESB process using phased implementation techniques. The tutorial provides stepby-step 

instructions to build ESB processes to retrieve and assemble data from 

multiple data sources into messages, redefine the granularity and packaging of the 

messages (transformation), and route the messages (and copies) to locations 

determined from the message´s data (content-based routing). 



For step-by-step instructions to develop the ESB processes yourself, see “Remote 

Information Access tutorial” in the “Progress Sonic ESB Samples and Tutorials” 

section of the Sonic Workbench online help. To watch an online demo of the entire 

tutorial, open the documentation portal for the Progress Sonic ESB Product Family 

(from the Start menu, select Programs > Progress > Sonic 7.6 > Documentation) and 

click on the link to the multimedia demonstration for the Remote Information Access 

tutorial. 

Enhancements to the File Handling Services 

The enhancements to the File handling services include: 

● A new runtime parameter, ConfigurationRequestDocument, is available to specify the 

configuration document. It is enabled for parameter substitution. The runtime 

parameter, ConfigurationRequestDocumentRuntime, is deprecated, hidden, and not 

available at runtime. ESB processes prior to V7.6 will continue to work, but the path 

of the .pickup or .drop file is not visible in Workbench. Verify this by opening the 

.esbp file with the text editor. 

● In addition to the existing cleanup actions, delete and none, the File Pickup service 

now provides move and rename. 

● The File Drop service now supports writing files in other encoding beyond the 

platform default, for example, UTF-8. The .drop file has a new tag. 

● A new runtime and initialization parameter, Content ID for Config Document 

specifies the Content ID of the input message part in a multipart message that contains 

the configuration document. If a numeric value is specified and no matching Content 

ID exists, the service queries the part with that index number for the content to use as 

the configuration document. 

● A new runtime and initialization parameter, Default Message Part, specifies either the 

index of the part or the Content ID of the part to designate where the File Pickup 

service places the picked up file content or where the File Drop service obtains the 

file content. The default value is 0, providing backwards compatibility. 

● There is a new initialization parameter, Retain Message. For the: 

■ File Pickup service: If the value is True, a new message part is created having the 

content of the picked up file. This part is appended to the message from the inbox. 

The default value is false. 

■ File Drop service: If the value is True and the 'EXIT' is provided as a status 

destination in the configuration document, the status message is appended to the 

inbox message. The default value is False. 



● The File handling services provide new metrics. 

The File handling services are documented in the “Progress Sonic Services” section of the 


Important: See the Sonic ESB release notes for information on upgrading the file 

handling services. 

Enhanced the Split and Join services 

The enhancements to the Split and Join services include: 

● New runtime and initialization parameters for the Split and Join Parallel service 

include: 

■ Merge Branch Results to specify whether to merge the branch results, either No 

Merge or Append Child Nodes. 

■ XPath Expression to specify the parent node for the merge results. 

■ Namespaces to specify the namespaces used by the XPath expression. 

■ Merge Part to specify the Content ID or index of the part to merge the results into. 

● New and revised runtime and initialization parameters for the Split and Join ForEach 

service include: 

■ Split Part was enhanced to specify the Content ID or index of the part of an input 

multipart message to split. The value is used first as a content ID for the part to 

be split. If the input message has no part with a matching content ID, the 

parameter value is parsed as an integer and used to retrieve a message part with 

that index. If no value is specified, part 0 of the input message is split. 

■ Merge Branch Results determines whether branch results are automatically 

merged, either No Merge, Replace Parts, or Replace Nodes. 

● New Split and Join service samples demonstrate the new merge options. 

The Split and Join services are documented in the “Progress Sonic Services” section of 

the Sonic Workbench online help. The samples are documented in the “Progress Sonic 

Samples and Tutorials” section. 



DB Navigator 

DB Navigator connects to any SQL-compliant database through a JDBC driver. This 

release includes the following enhancements: 

● When working with an OpenEdge database, you can use schema wizards to create, 

modify, and delete tables, columns, indexes, and other database objects. You can also 

view and create triggers and sequences. 

● When working with a Microsoft SQL Server database or an Oracle database, you can 

view extended schema elements such as triggers, functions, and stored procedures. 

● In addition to providing Type IV JDBC drivers for Progress OpenEdge, Microsoft 

SQL Server, Oracle, IBM DB2, Sybase, and Informix databases, DB Navigator also 

provides a connection using a JDBC ODBC bridge. 

● You will notice a change in the location and structure of the DB Navigator's 

Preferences, as well as a renaming of the perspective. 

ESB Configuration API 

The ESB Configuration API enables programmatic control over ESB configuration 

objects. With this API, you can retrieve, create, modify, and delete ESB endpoints, ESB 

services, ESB containers, and so on. You can also use this API to perform a variety of 

other tasks, such as creating activation daemons. 

Miscellaneous 

● Orchestration Server support was removed from Sonic Workbench, as well as the 

Orchestration editor, Process Set editor, and the Orchestration Developer's Guide. 

● The File > Import > Others > Sonic Project created with previous versions of 

Workbench option has been removed. It had been provided to assist with upgrading 

Stylus Studio projects. 

● Right-clicking on a WSDL or XSD in the Navigator view provides the Create New 

XML option to quickly launch the New XML wizard with the chosen file for selecting 

types/elements. 


Web Service Invocation Editor 


The Web Service Invocation editor has the following enhancements: 

● The Web Service Invocation editor supports a history of WSDLs used across ESBWS 

files. The Recent option is available in all places where URLS can be chosen from 

Sonic FS, as shown: 

● ESBWS files can be created from WSDL files by right clicking on port types and 

operations. 

● The Web Service Invocation editor supports validation of the WSDL file for the 

chosen service, port, binding, port type, and operation. Errors are shown in the 

Problems view. Navigating opens the WSDL file that is in error in the WSDL editor 

and the line with the error is highlighted. 

● The Web Service Invocation editor supports multiple faults when the ESBWS type is 

set to Fault. 

● The Web Service Invocation editor does not recreate the mappings if the changes in 

the WSDL do not affect it. 

● The Parameter Mappings table has several changes that make it easier to map 

parameters, including a new option to Discard input parameters. 

The Web Service Invocation editor is documented under “ESB editors” in the “Sonic 




ESB Process Editor 

The ESB Process editor has the following enhancements: 

● The ESB editor supports automatic uploading upon saving. This behavior is 

configured in the Preferences page. 

● The ESB Process editor supports refactoring a sequence of steps as a subprocess and 

ensures that both processes are valid. 

● The ESB Process editor provides a wizard for creating a WSDL. The wizard allows 

you to configure what is generated and to generate an ESB binding for the WSDL. 

● The ESB Process editor provides a wizard for wrapping an existing process with 

another process that is exposed as a web service. The wizard also creates all the 

required ESBWS files. 

● The ESB Process editor supports enabling and disabling breakpoints. 

● The ESB Process editor supports creating a subprocess from the process where it is 

being used, without having to create it ahead of time. Use the New option to create the 

subprocess, as shown: 

● Dropping a step on an ESB process in the Process page makes the service name 

editable. 

● The drop target on an ESB process in the Process page is wider for better drag and 

drop support. 

The ESB Process editor is documented under “ESB editors” in the “Sonic Editors” section 

of the Sonic Workbench online help. 


Enhanced Scenarios 

Scenarios have the following enhancements: 


● Scenarios support validation and can catch common mistakes such as empty input, 

file/literal confusion, and out-of-sync with the interface errors. 

● The Edit Scenario dialog box provides tool tips that display the file contents when you 

position the cursor over a file URL. 

● The Output view displays rejected messages in readable format, and provides links to 

the process and service steps at which the error occurred, as shown: 

● The Output view has an option to close all the output tabs.er 

● Multi-byte character streams are processed correctly because UTF-16 and other 

encodings are fully supported. 

Scenarios are documented under “Running and Debugging Sonic Applications” in the 

“Sonic Development and Debugging Tools” section of the Sonic Workbench online help. 

Enhanced Container Management 

The Containers view has the following enhancements: 

● The Containers view provides improved logging and tailing of container log files and 

integrates with the Eclipse Console view, providing additional features. 

● Container properties are viewable and editable in a Properties dialog box. 

● You can create and configure ESB containers in Sonic Workbench. 

● You can add ESB processes with endpoints and service to containers in Sonic 

Workbench. 



The Containers view is documented under “Container Management” in the “Sonic 


Java Service Type Editor 

Java Service development supports an improved XQServiceEx template based on common 

usage. It is the basis of the code generated when a new Java Service is created. The Java 

Service Type editor is documented under “ESB editors” in the “Sonic Editors” section of 

the Sonic Workbench online help. 

Deploy Directory and XAR Upload 

Sonic projects have a new deploy directory that can hold XAR files and exploded XAR 

files as directories. You can also extract and upload them. This functionality is 

documented under “Sonic archives (XAR files)” in the “Sonic Workbench” section of the 


Enhanced XPath Helper 

XPath Helper has the following enhancements: 

● XPath Helper has the ability to change input documents from within the dialog box. 

● XPath Helper can remember the document that was used to populate it in the specific 

context. For example, for a specific XCBR file, the next time the XPath Helper is 

opened, it opens with the same XML file. 

● XPath Helper handles namespaces correctly and has other improvements. 

XPath Helper is documented under “Generating XPath Expressions” in the “Sonic 

Development and Debugging Tools” section of the Sonic Workbench online help. 

Other Enhancements 

Other enhancements include the following: 

● Context-sensitive help is integrated into Sonic Workbench. Use F1 to invoke this help. 

● The Java Service Type editor and the BPEL Service editor have an option to specify 

the container in which to upload a service. The container is not restricted to 

dev_ESBTest for Java Services and dev_BPEL for BPEL Services. 

● A formatting preference creates all namespace declarations on new lines, making 

them easier to read. 



● The XML Schema editor and the WSDL editor support improved semantic navigation 

using F3 and Ctrl+Click for various items such as refs, binding, and port types that 

cross files, and follow the correct namespace, imports, and visibility rules. 

● The XML editor’s Tree page provides a dialog box for typing text and automatically 

encodes special characters such as &, >, and


BPEL Editors in Progress Sonic Workbench 

Sonic ESB 7.5 provides a richly-featured drag-and-drop BPEL editor and distributed 

debugging support for Sonic BPEL Server at runtime. Sonic Workbench introduces three 

new WS-BPEL 2.0 editors: 

● BPEL Editor — Create, edit, and validate BPEL processes (.bpel files) and configure 

deployment descriptors (.bpdd files). 

● BPEL Service Editor — Configure a BPEL service (.bpsvc file), which specifies one 

or more BPEL process definitions to deploy as a single BPEL service. Use a BPEL 

service to run and debug scenarios against a BPEL service deployed in a test 

container. 

● BPEL Invocation Editor — Define a BPEL invocation (.esbpel file) that specifies a 

WSDL operation provided by a BPEL process. When you add a BPEL service step to 

an ESB process, the BPEL service step references a BPEL service instance and its 

BPEL invocation. 

Each editor is documented in the “Sonic Editors” section of the Sonic Workbench online 

help. 

BPEL Configuration and Management Support 

You can configure and manage BPEL services using the Sonic Management Console 

(SMC). Use the SMC management features to search for BPEL process instances and 

view audit trails and events for each process instance. See the “Configuring BPEL 

Services” and “Managing BPEL Services” chapters in the Progress Sonic ESB 

Configuration and Management Guide (PDF). 

You can also perform management tasks programatically using the BPEL management 

API. This API is SOAP/WSDL-based and accessible via HTTP. See the Progress Sonic 

BPEL Server: Management API Guide (PDF). 

Advanced Web Services Interoperability 

Sonic ESB 7.5 was tested for advanced web services interoperability with Microsoft's 

new Windows Communication Foundation for WS-SecurityPolicy, WS- 

ReliableMessaging and WS-Addressing. See “Working with web services” in the “Sonic 

ESB Developer’s Guide” section of the Sonic Workbench online help. Also see the 

Progress SonicMQ Configuration and Management Guide (PDF) and the Progress 

SonicMQ Deployment Guide (PDF) for background information about configuring and 

deploying web services. 


Enhancements in Sonic Workbench 


In addition to the three new BPEL Server editors, Sonic Workbench has the following 

enhancements for V7.5: 

● WSDL editor — Provides Policy Wizards for WS-Security 2002, 2005, and WS- 

ReliableMessaging. The WSDL editor supports a greater range of WSDL files, and 

enables you to validate WSDL for WS-I compliance, in addition to performing basic 

validation. The Overview page is now directly editable. The WSDL editor also 

supports BPEL extensions (partner link type extensions, property extensions, and 

property alias extensions). See the “WSDL editor” topics in the “Sonic Editors” 


● ESB Process editor — Provides drag and drop support to replace implementation of 

ESB process steps. Dropping an artifact on a step redefines the step based on the 

dropped artifact. See the “ESB Process editor” topics in the “Sonic Editors” section 

of the Sonic Workbench online help. 

● ESB Message Editor — Supports JMS and ESB headers, including JMSReplyTo, 

when composing messages. See the “ESB Message editor” topics in the “Sonic 


● Message Sender and Message Listener views — Enable specification of a 

JMSReplyTo on messages and dragging and dropping messages. See the “Sending 

and listening for messages” topics in the “Sonic Testing and Debugging Tools” 


● Creating ESB endpoints — Sonic Workbench now supports creating basic ESB 

endpoints. See the “Creating ESB endpoints” topic in the “ESB Endpoints” section 

of the Progress Sonic ESB Developer’s Guide in the Sonic Workbench online help. 

Performance Improvements 

Sonic ESB 7.5 greatly improves ESB Process throughput and latency through internal 

optimization and caching, most notably on web services callouts. Additionally, the 

embedded HTTP Server in SonicMQ is redesigned to enhance performance with 

comparable performance improvements in HTTP tunneling, a key component of Sonic 

ESB’s capability to cross firewalls. See the “Configuring Acceptors” chapter of the 

Progress SonicMQ Configuration and Management Guide (PDF). 



Leverages Progress DataXtend Semantic Integrator 

Sonic ESB 7.5 dramatically simplifies common data model lifecycle management, 

transformation, and validation by leveraging the power of Progress DataXtend Semantic 

Integrator. This new capability tackles the problem of point-to-point transformations, 

making it much easier to integrate data and evolve a SOA with diverse connected systems. 

For information about Progress DataXtend SI, see Progress Software’s DataXtend web 

site at www.progress.com/dataxtend. 

Integrates Progress Actional for SOA Operations 

Sonic ESB 7.5 extends the integration with Actional for SOA operations to include 

instrumentation of Sonic BPEL Server. Actional gathers operational metrics, raises alerts 

on SLA failure, delivers real-time dependency tracking, and performs root cause analysis 

across the ESB and into the IT infrastructure it connects. For information about Progress 

Actional, see Progress Software’s Actional web site at www.progress.com/actional. 


Chapter 5 Learning More About the Progress Sonic 

Products 

This chapter describes where to find more information on the Progress Software products, 

as detailed in the following sections: 

● “Progress Sonic Documentation” 

● “Progress Sonic Infocenter” 

● “Progress Sonic Education and Training” 

● “Progress Software Developers Network (PSDN)” 

● “Progress Sonic Technical Support” 

● “Progress Sonic Evaluation Support” 


Chapter 5: Learning More About the Progress Sonic Products 

Progress Sonic Documentation 

Sonic installations always have a welcome page that provides links to Sonic 

documentation, release notes, communities, and support. See the release’s Product 

Update Bulletin book to see what’s new and what’s changed since prior releases. 

The Sonic 8.5 documentation set—accessed at PSDN or at its remote site—includes the 

following books and API references. 

SonicMQ Documentation 

SonicMQ installations provide the following documentation: 

● Progress Sonic Installation and Upgrade Guide — The essential guide for installing, 

upgrading, and updating SonicMQ on distributed systems, using the graphical, 

console or silent installers, and scripted responses. Describes on-site tasks such as 

defining additional components that use the resources of an installation, defining a 

backup broker, creating activation daemons and encrypting local files. Also describes 

the use of characters and provides local troubleshooting tips. 

● Getting Started with Progress SonicMQ — Provides an introduction to the scope and 

concepts of SonicMQ messaging. Describes the features and benefits of SonicMQ 

messaging in terms of its adherence to the JavaSoft JMS specification and its rich 

extensions. Provides step by step instructions for sample programs that demonstrate 

JMS behaviors and usage scenarios. Concludes with a glossary of terms used 

throughout the SonicMQ documentation set. 

● Progress SonicMQ Configuration and Management Guide — Describes the 

configuration toolset for objects in a domain. Also shows how to use the JNDI store 

for administered objects, how integration with Progerss Actional is implemented, and 

how to use JSR 160 compliant consoles. Shows how to manage and monitor deployed 

components including metrics and notifications. 

● Progress SonicMQ Deployment Guide — Describes how to architect components in 

broker clusters, the Sonic Continuous Availability Architecture and Dynamic 

Routing Architecture®. Shows how to use the protocols and security options that 

make your deployment a resilient, efficient, controlled structure. Covers all the facets 

of HTTP Direct, a Sonic technique that enables SonicMQ brokers to send and receive 

pure HTTP messages. 

● Progress SonicMQ Administrative Programming Guide — Shows how to create 

applications that perform management, configuration, runtime and authentication 

functions. 


Progress Sonic Documentation 

● Progress SonicMQ Application Programming Guide— Takes you through the Java 

sample applications to describe the design patterns they offer for your applications. 

Details each facet of the client functionality: connections, sessions, transactions, 

producers and consumers, destinations, messaging models, message types and 

message elements. Complete information is included on hierarchical namespaces, 

recoverable file channels and distributed transactions. 

● Progress SonicMQ Performance Tuning Guide — Illustrates the buffers and caches 

that control message flow and capacities to help you understand how combinations of 

parameters can improve both throughput and service levels. Shows how to tune TCP 

under Windows and Linux for the Sonic Continuous Availability Architecture. 

● SonicMQ API Reference — Online JavaDoc compilation of the exposed SonicMQ 

Java messaging client APIs. 

● Management Application API Reference — Online JavaDoc compilation of the 

exposed SonicMQ management configuration and runtime APIs. 

● Metrics and Notifications API Reference — Online JavaDoc of the exposed SonicMQ 

management monitoring APIs. 

● Progress Sonic Event Monitor User’s Guide — Packaged with the SonicMQ installer, 

this guide describes the Progress Sonic logging framework to track, record or redirect 

metrics and notifications that monitor and manage applications. 

Other SonicMQ Documentation 

The Progress Sonic download site provides access to additional client, and JCA adapter 

products and documentation: 

● Progress SonicMQ .NET Client Guide — Packaged with the SonicMQ .NET client 

download, this guide takes you through the C# sample applications and describes the 

design patterns they offer for your applications. Details each facet of the client 

functionality: connections, sessions, transactions, producers and consumers, 

destinations, messaging models, message types and message elements. Includes 

complete information on hierarchical namespaces and distributed transactions. The 

package also includes online API reference for the Sonic .NET client libraries, and 

samples for C++ and VB.NET. 

● Progress SonicMQ C Client Guide — Packaged with the SonicMQ C/C++/COM 

client download, this guide presents the C sample applications and shows how to 

enhance the samples, focusing on connections, sessions, messages, producers and 

consumers in both the point-to-point and publish/subscribe messaging models. 

Provides tips and techniques for C programmers and gives detailed information about 



releasing objects and about using XA resources for distributed transactions. The 

package also includes online API reference for the SonicMQ C client. 

● Progress SonicMQ C++ Client Guide — Packaged with the SonicMQ C/C++/COM 

client download, this guide presents the C++ sample applications and shows how to 

enhance the samples, focusing on connections, sessions, messages, producers and 

consumers in both the point-to-point and publish/subscribe messaging models. 

Provides tips and techniques for C++ programmers and gives detailed information 

about using XA resources for distributed transactions. The package also includes 

online API reference for the SonicMQ C++ client. 

● Progress SonicMQ COM Client Guide — Packaged with the SonicMQ C/C++/COM 

client download for Windows, this guide presents the COM sample applications 

under ASP, and Visual C++. Shows how to enhance the samples, focusing on 

connections, sessions, messages, producers and consumers in both the point-to-point 

and publish/subscribe messaging models. Provides tips and techniques for COM 

programmers. The package also includes online API reference for the SonicMQ 

COM client. 

● Progress SonicMQ 8.5 Resource Adapter for JCA User’s Guide for WebSphere — 

Packaged with this JCA adapter in a separate download, this guide describes the 

Sonic Resource Adapter for JCA and using it with a WebSphere application server. 

● Progress SonicMQ 8.5 Resource Adapter for JCA User’s Guide for Weblogic — 


Sonic Resource Adapter for JCA and using it with a Weblogic application server. 

● Progress SonicMQ 8.5 Resource Adapter for JCA User’s Guide for JBoss — 


Sonic Resource Adapter for JCA and using it with a JBoss application server. 

Sonic ESB Documentation 

The Sonic ESB product family provides the following documentation: 

● Progress Sonic Installation and Upgrade Guide — Provides information about 

installing, updating, and upgrading Sonic ESB components. 

● Progress Sonic Workbench User Guide (Progress Sonic Workbench Online Help) — 

Provides information about developing, testing, and debugging applications on the 

Progress Sonic Workbench. Describes the Sonic Workbench, its editors, and tools. 

Provides information about how to get started with each component of the Sonic ESB 

Product Family and describes sample applications. 

● Progress Sonic ESB Configuration and Management Guide — Provides information 

about configuring and managing components used by the Sonic ESB Product Family. 


Progress Sonic Infocenter 

Describes deployment configurations for Sonic ESB, Sonic Database Service, and 

Sonic BPEL Server 

● Progress Sonic ESB Deployment Guide — Provides information about moving 

development projects into test and production environments. Describes 

recommended build procedures, domain mappings, and reporting features. 

● Progress Sonic BPEL Server: Management API Guide — Describes how to use the 

management API to programatically access BPEL server functionality. 

● Sonic ESB API Reference — Online JavaDoc compilation of the Sonic ESB APIs. 

Progress Sonic Infocenter 

The Progress Sonic Infocenter provides an Eclipse-independent deployment of the Sonic 

Workbench online help in the Progress Sonic Workbench User Guide. Just use your 

preferred browser to access the Infocenter at: 

http://documentation.progress.com/infocenter/sonic/8.5. 

Progress Sonic Education and Training 

Choose from: 

● Instructor-led Training — Progress Software offers instructor-led lecture and exercise 

style training on-site at your location. Courses are taught by field consultants who 

have certified on the courseware, yet also bring practical experience to the classroom. 

● Subscription-based eLearning Service — Gives you access to the Progress Sonic 

Catalog, which is part of the Enterprise Infrastructure eLearning Library. Each 

student has unlimited online access to the Progress Sonic Catalog as well as the entire 

Enterprise Infrastructure library of eLearning titles. 

Progress Software Developers Network (PSDN) 

The Progress Software Developers Network, PSDN Online, is the technical community 

website for all Progress Software products. Browse through current technical 

whitepapers, shared code, evaluation versions, demonstrations, video presentations, and 

product documentation. PSDN Online is a dynamic, interactive, 24x7 community where 

developers contribute to the forums, blogs, ratings, watches, and comments. Access is 

free—just go to www.psdn.com and register. 



Progress Sonic Technical Support 

Progress Software’s Sonic support staff can provide assistance using the resources on 

their Web site at www.progress.com/sonic. There you can access technical support for 

licensed Progress Sonic editions to help resolve technical problems that you encounter 

when installing or using Sonic products. 

The Progress Sonic support program offerings include: 

● Tiered support services 

● Support centers located around the world 

● Electronic knowledge center for self-service 

● Access to our on-line developers network and related Web sites 

● Electronic software download capability 

When contacting Technical Support, please have the following information available: 

● The release version number and serial number of SonicMQ that you are using. This 

information is listed on the license addendum. It is also at the top of the SonicMQ 

Broker console window and might appear as follows: 

SonicMQ Continuous Availability Edition [Serial Number nnnnnnn] 

Release nnn Build Number nnn Protocol nnn 

● The release version number and serial number of Sonic ESB that you are using. This 

information is listed on the license addendum. It is also near the top of the console 

window for a Sonic ESB Container. For example: 

Sonic ESB Continuous Availability Edition [Serial Number: nnnnnnn] 

Release nnn Build Number nnn 

● The platform on which you are running Progress Sonic products, and any other 

relevant environment information. 

● The Java Virtual Machine (JVM) your installation uses. 

● Your name and, if applicable, your company name. 

● E-mail address, telephone, and fax numbers for contacting you. 

Progress Sonic Evaluation Support 

● United States, Canada & Latin America — +1 781 999 7100 eval@progress.com 

● Europe, Middle East & Africa — +44 (0) 1753 217000 info-emea@progress.com 

● Asia Pacific — sonic-eval-ap@progress.com

850_update_bulletin - Progress Sonic Product Update Bulletin 8.5

Create successful ePaper yourself

Delete template?

Save as template?