Invalid organization type

[Michael Oliver, geändert vor 9 Jahren.]

Trying to use the SOAP interface.

Cannot find the proper values for the Organization Type element.

The wsdl doesn't list the choices and I cannot find the list of allowable values.

null doesn't work and Regular Organization doesn't work.

Can you point me to the documentation or give me the value for Regular Organization.

[David H Nebinger, geändert vor 9 Jahren.]

"Regular Organization" is just the display name.

Use the internal values defined in the com.liferay.portal.model.OrganizationConstants class.

[Michael Oliver, geändert vor 9 Jahren.]

David H Nebinger:

"Regular Organization" is just the display name.

Use the internal values defined in the com.liferay.portal.model.OrganizationConstants class.

Lovely, what jar is that in? I am building a SOAP client to the WSDL I shouldn't need to be using Internal Values, the WSDL should define the choices. Even the portal-client doesn't have that class. Good thinking.

[David H Nebinger, geändert vor 9 Jahren.]

It's in the portal-service jar.

When developing against Liferay (web service or otherwise) it's always a good idea to have the source handy to help see how the portal does things. I find it's the most consistent and reliable documentation.

Honestly for the org type, I would probably guess it was left open for future expansion? I don't know for sure, but they tend to err on the side of future growth rather than painting themselves into a corner that's hard to get out of later.

[Michael Oliver, geändert vor 9 Jahren.]

Thanks David, I will get the values from there.

I guess you probably know the mindset of the developers not wanting to corner themselves....however, that's the same argument I have heard regarding the use of CONSTANTS...

A WSDL is meant to define the contract for SOAP clients to communicate with the service. The concept of the WSDL is to hide the implementation details. If a field has a required set of values, the schema should define the choices, a developer should NEVER need to look any deeper than the WSDL to build his client.

What makes this even worse, is that I am using the Liferay Client classes, so these classes come from Liferay yet they don't even provide proper validation for required values.

Thanks for the info, perhaps someone that runs into this gap, will find the answer here.

[David H Nebinger, geändert vor 9 Jahren.]

Eh, you're preaching to the choir here w/ respects to best practices...

Liferay is really a horse of a different color. It's not just a portal, it's also a framework, a foundation. It's not a canned system, but a really (really) open system that many different organizations will take and customize in their own separate ways. Liferay also had to deal w/ how to handle upgrades between versions, internet deployments, ... ;-)

So where Liferay may only envision "regular-organization", they leave the door open for the addition of any other type of organization that is necessary. They realize they cannot know all possible use cases nor do they want to deal with bugs because someone cannot add their own organization type. Leaving it open like that just makes the most sense.

So things that appear to us as unconstrained or "cowboy" coding was actually thought out and the decisions are based off of a larger set of requirements than we are typically aware.

Not that it helps you in your current task, of course, but hopefully it will explain why what may seem as a bad practice was actually done for good reason...

[Michael Oliver, geändert vor 9 Jahren.]

Just as a point of reference, I wrote my first program on punched paper tape in 1970. So I have seen a lot of best practices go by the wayside for "good reason" only to still be there frustrating developers years later. There has never been a shortage of Round Tuits.

A quick look at that CONSTANTS class shows something of interest...

public class OrganizationConstants {

	public static final int ANY_PARENT_ORGANIZATION_ID = -1;

	public static final int DEFAULT_PARENT_ORGANIZATION_ID = 0;

	public static final String TYPE_LOCATION = "location";

	public static final String TYPE_REGULAR_ORGANIZATION =
		"regular-organization";

}

There is ONLY ONE Organization Type in that class...so why not make the organization type in the WSDL with a default value of "regular-organization"? That would be less restrictive than a choice of one, and leave it open for "future", would it not? Should I put in an Jira issue in this or is this enough of a prod to get it improved for the next guy?

At least someone googeling on this problem will find the answer here.

[Jorge Ferrer, geändert vor 9 Jahren.]

Hey Dave, Michael,

Sorry that I'm a little late here, but I wanted to clarify that the values of the type param are not fixed in Stone. They are configured through portal(-ext).properties with the following property:

organizations.types

The class OrganizationConstants just contains some constants which include the default types, but I personally would not recommend using them since it may create a false sensation that those are the only valid values, and in fact they don't even have to be valid values depending on your configuration.

Having said all this, I think that this param should be optional when creating an organization through the API. What is needed in order to achieve that is either a new property that specifies what is the default type or, maybe even simpler, just pick the first type in the list when none is specified.

Thoughts?

[Michael Oliver, geändert vor 9 Jahren.]

Jorge,

Thanks,

Just to be clear, the problem is that from the WSDL we cannot tell what valid values to use. "regular-organization" as defined by the constants is the only value accepted unless ext-properties is modified as you suggest...the problem is that until you look inside the source code you cannot see what the value should be.

All I am saying is that the WSDL file should have a default value so we can build and use a client to access that SOAP service without having to research in the code, after all that is what an WSDL file is supposed to do. Being extensible is a good thing, that is not the complaint.

[Jorge Ferrer, geändert vor 9 Jahren.]

Hey Michael,

To avoid misunderstandings, the fact that there is a constant for "regular-organization" is completely irrelevant. The only relevant piece of information to determine the valid values for the "type" parameter are the configuration (portal.properties, portal-ext.properties, etc). If the organizations.types property does not have the value "regular-organization" the it won't be a valid value for the "type" parameter. Because of this, the source code should never be looked at for this.

Regarding your suggestion to specify a default value in the WSDL I don't think that is possible because any value set there as the default may end up not being valid if the configuration does not include it.

[Michael Oliver, geändert vor 9 Jahren.]

Jorge,

So what are we to do? We want to use the SOAP interface and generate a client from the WSDL. It will NOT WORK unless we look in the code or look at the documentation to find the need to set the properties. That is contrary to the purpose of a WSDL Contract. A default value may not be valid if you change the configuration, so what? A default value that works if you don't change the configuration, but can be overridden if you do sounds like the proper way to do it.

The SOAP interface as an afterthought, me too, feel good feature, when things like it not working unless you look deeper and change the configuration, or the the addOrganization operation does NOT work at all, shows a lack of understanding or care about those of us that need to use the SOAP interface for integration.

What if I do NOT want to change the configuration? What if I cannot change the configuration because I am a client to someone else's Liferay? You make it difficult to implement a SOAP Client.

I am a long time proponent of Liferay, we use it as a core element of our own services, we ave written hooks, we have developed custom portlets, we have integrated many applications, I have used SOAP/WSDL since there was such a thing. A WSDL should be all that is necessary to build a SOAP client. As it is today that isn't true for Liferay...PERIOD!

[Jorge Ferrer, geändert vor 9 Jahren.]

Hey Michael,

Sorry for the delay in my answer.

I'm no expert in WSDL, but I'm not sure I understand the concern. There is a parameter that is mandatory (and we've agreed that it would be better if it wasn't) and the values depend on your portal implementation (the Liferay platform comes with defaults but they can be changed). If you are developing a SOAP client for an specific portal implementation which has already decided what are the valid org types then you can add those to the WSDL.

Would that solve your problem?

[David H Nebinger, geändert vor 9 Jahren.]

I think that's the rub. The API allows for any value, but Michael thinks it should be more or less an enum value (since his implementation is not using a custom org type). For him, an open value where 'regular' is the only valid value is bad practice.

[Michael Oliver, geändert vor 9 Jahren.]

Jorge and David,

I understand that I can configure Organization Types and that those can be whatever I need and that the "regular-organization" is just a default value. No problem.

I also understand I can modify the WSDL for the SOAP web service to the Organization entity to match those custom organization types by modifying the schema referenced in the WSDL with <choice> elements to match the custom organization types that I might have configured.

Any WSDL is supposed to "Define" the contract with the SOAP interface. If you have an element defined that requires a value, then you MUST put that restriction in the WSDL. The WSDL for the Organization service...has the following schema for the Organization:

<complextype name="OrganizationSoap">
<sequence>
<element name="comments" nillable="true" type="soapenc:string" />
<element name="companyId" type="xsd:long" />
<element name="countryId" type="xsd:long" />
<element name="createDate" nillable="true" type="xsd:dateTime" />
<element name="modifiedDate" nillable="true" type="xsd:dateTime" />
<element name="name" nillable="true" type="soapenc:string" />
<element name="organizationId" type="xsd:long" />
<element name="parentOrganizationId" type="xsd:long" />
<element name="primaryKey" type="xsd:long" />
<element name="recursable" type="xsd:boolean" />
<element name="regionId" type="xsd:long" />
<element name="statusId" type="xsd:int" />
<element name="treePath" nillable="true" type="soapenc:string" />
<element name="type" nillable="true" type="soapenc:string" />
<element name="userId" type="xsd:long" />
<element name="userName" nillable="true" type="soapenc:string" />
<element name="uuid" nillable="true" type="soapenc:string" />
</sequence>
</complextype>

Note the <element name="type" nillable="true" type="soapenc:string"/> element shows nillable="true"

My point is that this WSDL defines this interface, and when you try to follow this "Definition" it fails because "type" cannot be "" and can ONLY be "regular-organization" if you haven't modified the configuration to change the organization types.

One should NOT need to look inside the source code or documentation to find out what values are allowable for a SOAP interface defined by a WSDL. The WSDL stands for Web Service Definition Language....it should define the Web Service and in this case it is absolutely WRONG.

Don't get me started...really, a variable field name called "type"....OMG!

David, no, the API does not allow any value...that's the point, it requires a value that matches the configuration, the WSDL needs to reflect what is required and it doesn't.

[David H Nebinger, geändert vor 9 Jahren.]

Michael Oliver:

David, no, the API does not allow any value...that's the point, it requires a value that matches the configuration, the WSDL needs to reflect what is required and it doesn't.

Sorry, Mike, I wasn't speaking directly towards the WSDL call itself, just the internal API requiring the organization type is an open string that will allow for any defined organization type. I can define an org type "extended-organization" and pass that as the type in the java API and therefore it would be an acceptable value for the web service call too.

Basically everyone is correct here. You are correct that there is a narrowly-defined set of org types and the WSDL should reflect that it is not a string field per se but actually a choice of valid options. I am also right in that it is not really a narrowly-defined set of org types and can be added or extended at any time, so defining it as a simple choice will fail as soon as I add additional org types.

[Michael Oliver, geändert vor 9 Jahren.]

David,

Ideally, the WSDL should be generated to properly reflect the actual Contract. If you change the configuration such that you have three organizations: regular-organization, government-organization and non-profit-organization, then when you request the ?WSDL the "orgType" would show a complex type with three choices.

Short of it being automatic in the above ideal case, then the WSDL needs to have a comment stating..."Organization Types are defined in the portal.properties" I would be happy to submit a WSDL as I now understand it if you like.

MO

[David H Nebinger, geändert vor 9 Jahren.]

The WSDL is not static, it is generated from the code by Axis.

[Michael Oliver, geändert vor 9 Jahren.]

I didn't say it was static, but also doesn't reflect the true contract either. It defines org "type" as nillable="true" when it requires the value to either be the default constant or one of the values configured. It should be generated FROM the actual contract.

[Michael Oliver, geändert vor 9 Jahren.]

Jorge,

See Jira Issue http://issues.liferay.com/browse/LPS-46257