Hi Richard,

That's a good question. I never really thought about it, but both should perform the same purpose. Generate SmartObjects will automatically create the category, and dump the SmartObjects into that category. Create SmartObjects allow you to specify the category to dump the SmartObjects into.

Create SmartObjects make sense for me when I already have a category created, and I want to dump all the SmartObjects into that category. I will only use Generate SmartObjects when I am lazy to create the category beforehand. I will just rename the category after the SmartObjects are generated.

Hi Richard,

The same question was asked before on one of the support tickets. Please see below information provided by our development team. 

Create SmartObjects

This option was designed for the Smartobject Tester tool only, which uses older application program interface (API) methods to create the SmartObjects and uses system name matching to do the updates. This isn't 100% safe, therefore, it is up to the user to make sure on the Create screen whether there are any clashes and whether the name needs to be appended – as a different SmartObject with the same name could be overwritten.

It will allow you to specify the category path location where to create the SmartObjects and whether you want to append the system name to make it unique. The names will be appended at the end of the name. This means that you can use the Create SmartObjects method to create multiple SmartObjects from the same ServiceObject by just appending the name differently every time.

Generate SmartObjects

This is the newer API method, which only publishes one SmartObject per ServiceObject of a ServiceInstance.

The ServiceInstance GUID and ServiceObject name is persisted in the SmartObjects metadata. When a generated SmartObject is the same as an existing SmartObject, it won’t be updated.

The SmartObjects generated category path is determined by the serviceType and ServiceInstance names plus folder structure. The SmartObject name will be a combination of the ServiceInstance name and serviceObject Name.

The Generate API is the preferred method used by K2 Management Site and SharePoint App.

Hi,

Thanks for the replies.  Sorry that I have not gotten back before this -- I've been battling a bad cold.

So, "Create" is the old way, while "Generate" is the new way.  First off, you may want to update the K2 learning material to reflect this change ...

Secondly, let me see if I understand the change correctly.  The old method, "Create", wasn't 100% safe, because it used the "system name" to "match up" when doing updates.  After some review of the environment, I take it that the "SystemName" is the name given to the SmartObject within the K2 database.  Now, if one autogenerates the SmartObjects, this will be the name coming from the data provider.  Further, this base name may be modified on a limited basis by appending some qualifier to make it unique.  From the suggested qualifier, I take it that the qualifier is the normally the name of the specific data source (e.g., database name).  The implication of the foreging is that K2 uses the SmartObject SystemName in its create / retrieve / update operations.  Consequently, if I try to create a SmartObject with the same name (no differentiating qualifier) but a different data source (e.g., different database), rather than creating a second object, K2 will instead update the existing object.

The new "generate" approach avoids the potential safety problem by persisting additional data about the SmartObject.  Thus, although SmartObject names might be the same, this additional internal information serves to differentiate berween the two.

Is the foregoing correct?

Thanks,

       Richard

Hello Richard,

Thank you for the feedback on our Documentation. You can also make update requests to the Documentation by using the Somewhat Helpful link at the bottom and writing your feedback.