OutDocumenter 2.2

OutDocumenter 2.2

Hi everyone,

It's been a while since I posted in the forums...

I'm pleased to announce the community that version 2.2 of OutDocumenter is out.
It brings with it a set of new reports, a new style guide, extended support to Agile Platform 4.2 and some bug fixes.

Check it out here: http://hubedition.outsystems.net/OutDocumenter
Hey André,

Why is it not possible for me to use OutDocumenter ?
I get certificate errors ... does not generate documents for me.

How do I get the documentation out of my OML ?
Hi Joop,

I don't see why you'd get certificate errors. The certificate is valid as you can see in the attachment.
Nonetheless you can also try using http://hubedition.outsystems.net/OutDocumenter

Hi André,

Could you guys consider adding the OutDocumenter to the Network ?
It's a great resource and it would be easier for us to be able to access it from the network.

It seemed to have to do with the fact that we're behind a proxy of our customer.
I tried it out at home and was able to start it without any problems.

However ... only the diagram can be used.

Missing Evaluation report and Tracebility
Is it possible to try out the evaluation and Traceability reports?

Kind regards,

Matthias Preuter

Hi Mathias,

The Evaluation and Traceability reports are currently internal to OutSystems only.

On the positive side I can let you know that the documentation will soon also be possible to generate for 5.0 eSpaces and solutions.

Best Regards,
   Pedro Oliveira

Is there an other way to: "Check adherence to OutSystems Best Practices. Detect unused code.
Audit Advance Queries.Audit Cascading Style Sheet"?

Kind regards,
OutDocumenter was created and is supported by OutSystems Professional Services for internal use and is not in itself an "OutSystems Product". As such they get to decide what part of it should be available to the outside world.

Regarding best practices let me draw your attention to the set of documents found at http://www.outsystems.com/NetworkDocuments/DownloadsEntry.aspx?VirtualDirectoryId=24 which provides very insightful guidelines on what are the recommended best practices.

Hope this helps.

Best Regards,
one more vote to turn this tool as part of the platform (maybe integrated in servicecenter ...)
Vote +1!

One more vote!

Vote +1!

Vote + 8,400,000 (Regional votes in The Netherlands had a very low count of people actually voting; I've collected them and just published them here, hope it helps)

Eric said:
Vote + 8,400,000 (Regional votes in The Netherlands had a very low count of people actually voting; I've collected them and just published them here, hope it helps)

Wow! Thanks for the hard work collecting the votes --- you deserve an extra +1 vote right there! :)

However, I'd like to hear about your requests for having this integrated in the platform. This being a public web application should suffice, right?

As Pedro put it, OutDocumenter was created and is supported by OutSystems Professional Services team for internal use and is not in itself an "OutSystems Product". As such they get to decide what part of it should be available to the outside world.

However, let us know what use cases are we missing that we should be covering - it will help us get a better understanding of what your needs are.

Best regards,

Paulo Tavares
Hello Paulo,

I think that OutDocumenter is a wonderful tool (have any idea when it will come out to support 5.0?) and that the design mode allows to generate documentation and with a little work hand it out to the customer.

On the development side it is also great the option of checking Best Practices and unused code.

I understand that a lot of the unused code exists now as a warning in Service Studio, but all the information on best practices is useful to accelerate development. Ok, so put it embedded on True Change could be a wonderful thing, but it would have to be perfect and avoid what i would call of necessary warnings (which can be a pain).

So if one had an option on service Studio or at least Service Center to check the oml for best practice implementation i am sure that it would be easier to do better and harder to do messy stuff in the code.

So It's an Outsystems Professional Services tool and they decide....Can you then please ask them what they think of sharing it on full scale, or even make it open source and make it a public add-on ?

Best Regards,

Diogo C S Cordeiro

Or maybe, if it is not integrated with Service Center, make it 'open source' by donating it as a downloadable components section?

Kind regards,
Matthias Preuter
The Netherlands (1 of 8.4 milj. votes)
vote +1, since I like the idea :D

I agree with bruno rabino, and his suggest to include the outdocumenter into the service center.

Vote + 1 

Vote + 1
Vote +1

Vote + 1
+ 1

Vote +1
Hi Paulo,

An OutDocumenter can be a good aid for us in several situations:

We (as in our business) regularly get's visits from auditors that want to investigate:
- Our system's procedures
- How the systems handles exceptions cases
- What flows exist in the system
- What communication is done by the system
- What checks exist in the system (e.g. if there is an accounting system connected, how is verified that the transmitted data is actually received / handled)
- How Authorisation is handled

External companies that want to connect to us that would like to know how received / sent data is handled.

New IT employees that aren't used to a -previously written- application that we would like to inform about the process / functions involved.

In case of changes done to the system it could give a good overview in case external bookkeeping applications want to retrieve data from the system; it can enable them to get presented which data is actually stored.
Of course it als gives them an idea of which data isn't stored yet and they would like to have stored.

Hope this gives a good global idea of the use of an autodocumenter.

Hi Eric,

Looking at your latest post everything you mention seems to be covered by the Design Document which is public domain, do you agree?

Agree, but the following functions would be very usefull too:
- Automatic checks on Best practices
- a Dictionary like posted here


Matthias Preuter
Hi André,

If you mean the OML, when referring to the Design Document ; yes; ofcourse; but this is not something that you can present to auditors /
customers because of the detail and the lack of layered structure (no post / preconditions) ; too much logic.
It's just that a documenter should give a more structural display of the actual design, dropping out the (non visual) detail level and local variables etc..

It's should represent the design in a report form which is readable for people that have a less technical experience level.

An (auto)documenter should present it's user with zoomable layers.
A global layer presenting the main structure in which the user can drill down to a more technical level.
Hi Eric,

Design Document stands for OutDocumenter's Design Document not the eSpace, although the Design's Document is nothing but a different view over the same information the eSpace holds, it's intended just to be more readable just the way JavaDocs is.

The purpose of this document is to be read by technical people, this is not a business overview of the code, although you can try to achieve this by removing some of the more technical information from the document itself.

Regardless of all this I think that you're idea is a very good one. Bearing in mind that we can only extract information that's present in the eSpace what do you think should be in that non technical report?

Hi André,

Excuse me for not being familiar with the Design Document itself.
I'm currently responding merely of the possibility of having an autodocumenter and I'm therefore projecting the needs.
Please consider my response in a 'this is what I would expect the autodocumenter to do' kind of attitude.

I'm not familiar with the OutDocumenter itself, but I am familiar with handling audits and the knowledge level and
'requirement list' auditors and Less technical users have.
New end-users of our company would be able to understand better what the company really does and how the
processes are automated when they get the process information described at the level that they can comprehend.

When looking at a programmed system, I think the 'global level' should consist of a three viewtypes;
  1. External information flows
  2. Internal information flows
  3. The two combined
The decision of which system is INTERNAL and which is EXTERNAL actually depends on the users point of view; grouping these and being able to select specific groups would be a good thing to implement in an autodocumenter.
(What I mean by this; from an auditors point of view; a document information system attached to an outsystems applications would be part of the an internal flow but for a programmers point of view everything outside the outsystems application would be EXTERNAL; even other Outsystems applications that communicate with each other using webservices)

Above viewtypes could be split-up in different interaction types having both an (Incoming / Outgoing) flow direction:
  • Human interfacing activities
  • Document flows
  • EDI flows
  • Web(service)flows
  • Other
The Outsystems environment kind of 'forces' me to create layered levels of functions so I can have a good overview.
e.g. I have a input order process which consists of multiple actions that call functions and those also call functions etc.
These are detail levels that you should be able to enter as a parameter for a report.

A very good option is creating an HTML document that enables the user to 'zoom' in to the called actions / functions.
(If you know the application Edge Diagrammer; you know what I mean with zooming in) 
Clicking on a document (in- or outgoing) flow could e.g. present a user with an example document, giving 'feeling' with the process.

Besides a good document that gives a view of what the application does and how it handles particular situations,
Auditors also often want an extract of the users and their permissions.
This is to check whether there are mangled interests (I hope that's the correct English word for what I mean).
A check for this in a tool like the Enterprise Manager would also be a very powerful thing to implement.
e.g. the ability to create check whether there is no user that has both accounting permission and stock change permission.
Vote + 1

Thank you for sharing your thoughts with us.

You're welcome André;

I expect to be using OutDocumenter soon; I'll give some more accurate feedback as soon as I've tried it out.
Hi André,

I've tried the outdocumenter but it gives below error:
Hi Eric,

I'm afraid OutDocumenter is not yet 5.0 ready.
We're making an effort to update it. Expect news about this shortly.


Hi André,

Thanks, I'll await the newer version / newsletter than.




I think http://hubedition.outsystems.net/OutDocumenter is not available anymore.
Anyone knows why?

Best Regards,
Nuno Mendes

Hi Nuno,

OutDocumenter has moved here: http://outdocumenter.outsystems.net/.

Thanks André.

Best Regards,
Nuno Mendes
Is there any newer informationon this topic?  I'm looking for a tool that will document which actions, screens, entities, etc. are in each eSpace. mAybe some other info also. I am on version 8.
Hi David,,

Have you looked at the OutDoc component that is available at the forge?
It allows part of this.

Also the OutDoc is open sourced, so you can see how it generates the reports from module and create what you need from it, if the default report is not enough.

João Rosado
By your amwser (João Rosado), can I understand that is not expect new improvements in OutDoc?

It's a pity!!!
Hi Alberto,

I would say that you should expect new improvements done by the community. I would really love to see a new component ramping up from the OutDoc that is publish in the Forge. Do you accept the challenge ;)?
I will consider... (I am not sure I have already the capability to do it)
I'll look in the Forge. As time permits and hopefully help for the commuity, I may give it a go to improve.