| Author |
Message
|
| zhaider |
 Posted: Thu Sep 08, 2016 2:25 am Post subject: IIB Integration Design Document Example/Template/Sample |
 |
|
Apprentice
Joined: 08 Oct 2015
Posts: 40
|
| Is there anyone has design document example/templates to describe the IIB/ESB integration objects? I'm acually working on a new design and it would actually help me on how to go about it. I have never done an integration/middleware work with IIB before, so I'm looking for some heads up. Especially how to cope with exceptions and such in your middleware proects. |
|
| Back to top |
|
 |
| ruimadaleno |
| Posted: Thu Sep 08, 2016 3:48 am Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
maybe some detail can help us , do you want an high level design or something more detailed ? some examples for clarification 
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Sep 08, 2016 3:51 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You can look in devworks for articles that talk about IIB, there may be bits and pieces you can assemble.
For high level system connectivity diagrams, or even slightly lower level like application to application/message flow, I tend to use just boxes and arrows.
EDIT: you can also export documentation for a flow (unless they've removed that in IIB v9/10). This can also provide you some templates.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Sep 08, 2016 4:26 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| mqjeff wrote: |
EDIT: you can also export documentation for a flow (unless they've removed that in IIB v9/10). This can also provide you some templates. |
It is still there in 10.0.0.6 but every time I try to use it, it reports that it can't complete because there is some non ascii character in it. no indication as to what the problem character is (naturally)
ASCII??? in 2016?
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| zhaider |
| Posted: Thu Sep 08, 2016 4:33 am Post subject: |
|
|
Apprentice
Joined: 08 Oct 2015
Posts: 40
|
| ruimadaleno wrote: |
| maybe some detail can help us , do you want an high level design or something more detailed ? some examples for clarification |
Of course I would like it to be as detailed as possible. But basically anything will be enough for me at this point. I'm basically designing an integration solution for a Bank with many of their different systems and of course their core banking system. I have in my mind what the message models and format I'll be using for different application connectivity etc.
Basically in general I want these design questions to be answered:
- Workspace Organisation
- Like how do you usually manage models, formats, subflows and main flows in projects and applications
- Exception Handling
- Coding Convention
- Notification Framework
- Store and Forward (SNF) framework |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Sep 08, 2016 6:11 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
A design document should be as much as possible generic. i.e. It does not matter what product you are using to solve the problem.
Then it is down to the development team how the requirements (inputs, outputs etc) contained in the document is met.
As the saying goes, there are several ways to skin a cat.
This does not stop the development team creating their own internal docs for support and maintenance. This is where the good bits, the neat tricks etc are documented for posterity.
For example a webservice in IIB could use SOAP Nodes (preferred) but there are times when it is a better solution to use HTTP nodes.
IMHO, you really don't want to tie yourself down to using SOAP nodes in the spec. Sometimes going back to the customer and saying 'sorry, we goofed and we need to change this...' is not the easiest thing in the world.
YMMV
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| ruimadaleno |
| Posted: Thu Sep 08, 2016 6:17 am Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
| zhaider wrote: |
| ruimadaleno wrote: |
| maybe some detail can help us , do you want an high level design or something more detailed ? some examples for clarification |
Of course I would like it to be as detailed as possible. But basically anything will be enough for me at this point. I'm basically designing an integration solution for a Bank with many of their different systems and of course their core banking system. I have in my mind what the message models and format I'll be using for different application connectivity etc.
Basically in general I want these design questions to be answered:
- Workspace Organisation
- Like how do you usually manage models, formats, subflows and main flows in projects and applications
- Exception Handling
- Coding Convention
- Notification Framework
- Store and Forward (SNF) framework |
Ok, i undestand your needs. In my actual project i've done something like that.
From what i understand you are trying to build a document with a set of guidelines/rules/policies that all development teams should apply on all projects they implement.
Maybe you don't have a lot of time but if you need something to show up quickly .. so maybe you can quickly draw a draft in a powerpoint and then proceed you work with a document (pdf/docx)
Maybe you can create a powerpoint , name it "company XZY broker/iib policies/guidelines". In each slide you cover one of the topics (exception hadling, notification framework) with some printscreens and sample diagrams drawn in powerpoint it self.
In a more mature version, you should have a docx/pdf covering all stages of a message flow lifecycle: design/deployment/operation (maybe one docx/pdf for each one of the stages) with some pictures/diagrams and text to support and explain some options taken.
One example (with some detail).
Exception Handling
--------------------
Every flow developed for the company xxxx should use the function writeException available in the xpto Library.
<<-- image with tookit screenshot showing exception handling usage -->>
An example of the output of an exception list is:
<<-- image with example of the "standard" exception -->>
-------------------------------------
As you can understand, this kind of document it tailored for an company, you don't have an "one size fits all document", so we can only show you some pointers to guide you in your quest.
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
|
| zhaider |
| Posted: Thu Sep 08, 2016 7:46 am Post subject: |
|
|
Apprentice
Joined: 08 Oct 2015
Posts: 40
|
| ruimadaleno wrote: |
| zhaider wrote: |
| ruimadaleno wrote: |
| maybe some detail can help us , do you want an high level design or something more detailed ? some examples for clarification |
Of course I would like it to be as detailed as possible. But basically anything will be enough for me at this point. I'm basically designing an integration solution for a Bank with many of their different systems and of course their core banking system. I have in my mind what the message models and format I'll be using for different application connectivity etc.
Basically in general I want these design questions to be answered:
- Workspace Organisation
- Like how do you usually manage models, formats, subflows and main flows in projects and applications
- Exception Handling
- Coding Convention
- Notification Framework
- Store and Forward (SNF) framework |
Ok, i undestand your needs. In my actual project i've done something like that.
From what i understand you are trying to build a document with a set of guidelines/rules/policies that all development teams should apply on all projects they implement.
Maybe you don't have a lot of time but if you need something to show up quickly .. so maybe you can quickly draw a draft in a powerpoint and then proceed you work with a document (pdf/docx)
Maybe you can create a powerpoint , name it "company XZY broker/iib policies/guidelines". In each slide you cover one of the topics (exception hadling, notification framework) with some printscreens and sample diagrams drawn in powerpoint it self.
In a more mature version, you should have a docx/pdf covering all stages of a message flow lifecycle: design/deployment/operation (maybe one docx/pdf for each one of the stages) with some pictures/diagrams and text to support and explain some options taken.
One example (with some detail).
Exception Handling
--------------------
Every flow developed for the company xxxx should use the function writeException available in the xpto Library.
<<-- image with tookit screenshot showing exception handling usage -->>
An example of the output of an exception list is:
<<-- image with example of the "standard" exception -->>
-------------------------------------
As you can understand, this kind of document it tailored for an company, you don't have an "one size fits all document", so we can only show you some pointers to guide you in your quest. |
Yeah kind of like the guide lines but not for all projects. I'll tailor it to my specific needs and fit in my solution for that particular project and then share it with my client for etc.
I'll greatly help me if you had any sample lying around or some old doc that's not useful for you guys any more or you could replace your objects with dummy name. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Sep 08, 2016 8:50 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Quote: |
Yeah kind of like the guide lines but not for all projects. I'll tailor it to my specific needs and fit in my solution for that particular project and then share it with my client for etc.
|
Why not for all projects?
Many of us who comment here work within the constraints laid down in our organisations for very good reason.
For example, Logging and exception handling are very often implemented identically on all projects.
Having a common logging and exception handig framework saves endless re-inventing of the wheel by each and every developer.
One of the questions I ask of any potential employer is about this sort of framework.[1]
Sometimes it does not exist so I get to implement it for them. If it exists then great. Then I know they are serious about the use of thie product.
Having a well used set of tools like this in your back pocket is also a good way to make yourself well thought of in a new assignment.
[1] I won't be doing that any longer because as of the end of the month, I'm retiring.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Sep 08, 2016 9:06 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| smdavies99 wrote: |
| [1] I won't be doing that any longer because as of the end of the month, I'm retiring. |
Golf?
Open a bar?
Sit on the beach and drink too many mai tais?
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Sep 08, 2016 9:24 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| smdavies99 wrote: |
| [1] I won't be doing that any longer because as of the end of the month, I'm retiring. |
Golf?
Open a bar?
Sit on the beach and drink too many mai tais? |
Party at MQTC? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Sep 08, 2016 9:36 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Vitor wrote: |
| mqjeff wrote: |
| smdavies99 wrote: |
| [1] I won't be doing that any longer because as of the end of the month, I'm retiring. |
Golf?
Open a bar?
Sit on the beach and drink too many mai tais? |
Party at MQTC? |
Golf? You have got to be kidding
Open a Bar? Nah, I'd swllow the profits
Sit on beach? Even worse than Golf
Party at MQTC? I'd love to do that but only if you will pay for my travel.... 
{only joking}.
Maybe next year.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| timber |
| Posted: Thu Sep 08, 2016 1:26 pm Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
Retiring? What is this thing of which you speak?
Old programmers never die. They just terminate and stay resident. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Sep 08, 2016 10:20 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| timber wrote: |
Retiring? What is this thing of which you speak?
Old programmers never die. They just terminate and stay resident. |
good one... 
I never managed to get my feeble attempts at a TSR to stay 'R' after 'T'.
give me a VMS or an RSX-11 Driver to code any day.
Your time will come Tim... your time will come.
Anyway, who says that I'm going to stop coding? There are a couple of FOSS projects that I'm already associated with that could easily see me keep coding for a while yet.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| zhaider |
| Posted: Thu Sep 08, 2016 11:18 pm Post subject: |
|
|
Apprentice
Joined: 08 Oct 2015
Posts: 40
|
| smdavies99 wrote: |
| Quote: |
Yeah kind of like the guide lines but not for all projects. I'll tailor it to my specific needs and fit in my solution for that particular project and then share it with my client for etc.
|
Why not for all projects?
Many of us who comment here work within the constraints laid down in our organisations for very good reason.
For example, Logging and exception handling are very often implemented identically on all projects.
Having a common logging and exception handig framework saves endless re-inventing of the wheel by each and every developer.
One of the questions I ask of any potential employer is about this sort of framework.[1]
Sometimes it does not exist so I get to implement it for them. If it exists then great. Then I know they are serious about the use of thie product.
Having a well used set of tools like this in your back pocket is also a good way to make yourself well thought of in a new assignment.
[1] I won't be doing that any longer because as of the end of the month, I'm retiring. |
Yeah, I get what you are saying with rest to all projects like the exception handling and logging framework. What I mean that I'll tailor it to my specific project is I'll also be including the service interfaces and models that I'm specifically building for this particular project.
So, is there any template guys? |
|
| Back to top |
|
|
|
|
