We recently upgraded from ODM 8.10 to ODM 8.11.
I have used #JsonPropertyDescription annotation to have descriptions added to variables of input and output object when generating a swagger (using the "Retrieve HTDS Description File" and OpenAPI - JSON option). The code:
#JsonPropertyDescription("Description here")
private String id;
The project code stayed the same and it doesn't seem to work in ODM 8.11 anymore. Descriptions nor default values for objects made by the user are not added to the generated Swagger. Descriptions for default variables and objects remain (such as __DecisionId__ or Error object).
Is it a bug in ODM 8.11? Or am I supposed to use different annotations?
Related
I'm using Visual Studio 2019 to make a VB .NET to make a WPF application for windows. I'm trying to use the Salesforce SOAP api to grab data from it. In the solution explorer I right click on my project -> Add -> Service Reference -> advanced -> add web reference. I put in the link to the enterprise WSDL file I downloaded from Salesforce. In my project I have a simple test button setup that runs this to try and login:
Dim SFService = New SFAPI.SforceService
Dim loginResult = New SFAPI.LoginResult
loginResult = SFService.login(userID, userPass)
My issue is that I get some errors stating that the autogenerated References.vb has errors and they are as follows:
Error BC30663 Attribute 'GeneratedCodeAttribute' cannot be applied multiple times.
Error BC30663 Attribute 'SerializableAttribute' cannot be applied multiple times.
Error BC30663 Attribute 'DebuggerStepThroughAttribute' cannot be applied multiple times.
Error BC30663 Attribute 'DesignerCategoryAttribute' cannot be applied multiple times.
Error BC30663 Attribute 'XmlTypeAttribute' cannot be applied multiple times.
Warning Custom tool warning: Schema could not be validated. Class generation may fail or may produce incorrect results
Warning Custom tool warning: Schema validation error: Schema item 'simpleType' named 'FaultCode' from namespace 'urn:fault.enterprise.soap.sforce.com' is invalid. The Enumeration constraining facet is invalid - 'fns' is an undeclared prefix.
Warning Custom tool warning: Schema validation error: Schema item 'simpleType' named 'FaultCode' from namespace 'urn:fault.enterprise.soap.sforce.com' is invalid. The Enumeration constraining facet is invalid - 'fns' is an undeclared prefix.
Any help would be greatly appreciated. Thank you!!
In cases where you get errors related to an attribute being applied twice, this usually means that there is a duplicate vb file somewhere. Best thing to do is to hit the icon in your solution explorer to show all files: . There's probably a file being hidden/causing a duplicate here.
Ultimately, there's duplicate attributes being seen by the compiler, which is a failure, unless you specifically allow duplicate attributes.
I know that local.Properties overrides project.Properties.
I also know that that these files define… database connections, ports, build environment, frontend HTTPS, etc.
I further know that project.Properties contains more properties.
Will appreciate if Hybris experts tell me syntax of local.Properties, illustrating with some example.
Please provide correct info.
If we talk about the syntaxes of entries in the project.properties file, then it is key=value
The property files in the hybris are of two types:
The extension level - The property file project.properties is the configuration file that carries properties in the key-value pair for the configurations involved on the extension level For instance, Consider a property in the project.properties of the yacceleratorstorefront (storefront template) extension storefront.storelocator.pageSize.Desktop=10 which clearly indicates the 'StoreLocator' results page size configuration per store. Since the store locator functionality is specific to the storefront and has no relevance for the other modules (like core, facades etc), the property is kept at the extension level.
Please note, project.properties reside in the extension folder
The global level - This is the property file which is the global configuration file, and deals with the properties are extension agnostic and carry a global impact. For instance the property commerceservices.default.desktop.ui.experience=responsive sets the ui experience to responsive mode that specifies the deployment to be for the responsive format.
The local.property file supersedes all of the properties with the same key that is defined in any of the project.proprties.
Please note, the local.properties file reside in the hybris/config folder
The hybris registry creates a property configuration map which constitutes all of the properties mentioned in the deployment configuration. The same could be managed in the HAC under platform/configuration.
The clear intent of the local.proprties file is to have information which either requires to be overriden on a global level. The override may be of different types, e.g. cart expiry time could be made different on different environments by the use of the local.property files.
For further reading, please refer to the link: https://wiki.hybris.com/display/release5/Configuring+the+Behavior+of+the+hybris+Commerce+Suite
property call hierarchy (from primary to secondary):
java -Dproperty.key=something
hybris/config/local.properties
hybris/*/(extension-name)/project.properties
hybris/bin/platform/project.properties
and within java code:
configService.getString("property.key", "last fallback value, if no propertyfile provide this key");
You could review all current variables using the hac interface for properties: http://localhost:9001/platform/config
I am busy with configuring our new TFS 2015 server (on premises) and trying to get the new vnext builds to work properly.
What I now have are some extra powershell scripts that increase the version number of my assemblies.
It also changes the buildnumber in TFS by calling the API method (see tfs rest api). My json body only sends the new build number (eg. {"buildNumber": "1.0.1.1234"}) and this works fine.
Now I have added some major, minor and patch version variables in the build definition for the version. Once the build is done this should be updated and so I thought to do the same kind of thing and just send an update API call to the corresponding builddefinition endpoint. The documentation says the revision number is mandatory so I have added that. For the rest I only added the changed variables.
The api call works, but the nasty thing is that it will update the whole definition and clear out all the other settings which I did not provide in the json body. I also tried first getting the defintion through the API, changing the json values for the variables and send that back but that didnt work correct also.
So does anybody know a good solution for this?
As a workaround what I did for now is adding a dummy build definition (eg. "_ProjectVersion") totally empty except for the variables and my build task now uses that build definition to get the latest version numbers and update them. So the api call still empties that whole build definition but since it only contains my variables I dont mind.
I am also doing this in powershell since all scripting should be automated and done in powershell.
The problem I have is that the API call to get the json of an existing BuildDefinition returns invalid json when managed in powershell.
For example the "#{multipliers=[]; will fail with 'must have at least one value' even though a 'json validator' may report as Valid. The correct json is {"multipliers": "[]",
I want to post a message to a SOAP webservice with MULE Enterprise edition.
For creating the Request object i am using a data mapper with the
input a POJO and for
the output i selected XML , and from example XML schema i added my own XSD.
Because there are a lot of elements in the xsd, i selected the root element from the list provided.
Then i am dragging the fields from input to the corresponding values i want in the output.
(i also tried to map just one field, to be sure that i keep the minimum the probability for error).
And now the problem:
when the flow is accessed, the following WARN is shown and the data-mapper fails
*[XML WRITER:EXT_XML_WRITER0] - Invalid mapping (With port binded to root element, result might contain multiple root elements. Such XML is not well-formed. To avoid that, set 'Records per file' or 'Max number of records' component attribute to '1'.)*
Where can i set this kind of options in the data mapper ?
And also i want the root element to be only one, i don't need a foreach for the root element, i just need to fill the contents of it. Can i specify this anywhere in the data mapper ?
Thanks.
Mule EE DataMapper uses CloverETL for data transformations, and this annoying warning concerns CloverETL settings. I don't know if you can advise CloverETL to use a specific configuration file in the context of Mule DataMapper, but you can always edit the mapping file generated by Mule with a text editor. Just find your root Node entry in the mapping file and add recordsPerFile="1" attribute.
The problem with this is that Mule may overwrite your manual edits if you use the graphical editor, though.
Check out the Anypoint Studio May 2014. Mule now includes a new Web Service Connector for posting messages to a SOAP web service using just a WSDL. Studio will read the XML Schema from the WSDL and automatically create the metadata for DataMapper for you. See http://www.mulesoft.org/documentation/display/current/Web+Service+Consumer for more details.
It seems that once an Ocean Workstep derivative class has been released to production (and is used by clients), its name, namespace and assembly name are effectively locked for future updates (in order to ensure backwards compatibility).
When a Petrel project is saved, workstep references are saved as a full type name (namespace, class, strong assembly name) inside the binary file Classes.ptd. During loading, if the exact type name (assembly version seems to be ignored) can't be resolved, the workstep appears as "workstep not available" in the workflow editor.
In other instances of binary serialization we've encountered, Petrel makes use of the SerializationBinder registered with PetrelSystem.ProjectSerializationService - not so for Workstep instances.
Is there any other way to facilitate Workstep class/namespace/assembly renames?
Why is this behaviour so poorly documented (if at all)? Have we misunderstood something?
This issue will actually be fixed with the Ocean 2012.1 API. The workstep reference will not include the version number anymore: Both workstep and process serialization is cleaned up. Version number is not serialized (and not used on deserialization) and a UniqueId can be used instead of the type name.
Here is an extract of the 2012.1 Ocean release notes on the subject.
Process and Workstep Unique Id
Namespace: Slb.Ocean.Petrel.Workflow
Processes and worksteps created through Ocean did not have a proper identifier until now. They were identified by their full type name including the version number which means that their identifier could change, for instance, if:
- The version number of the plug-in assembly was increased (e.g. new plug-in install).
- The process/workstep class was moved to a new assembly.
- The namespace of the process/workstep class was changed.
This could cause issues in Petrel such as the display of a “broken link” instead of the process name in the Favorites tree or a workstep appearing as "workstep not available" in the workflow editor.
To solve this, Ocean has removed the version number from the process and workstep identifier and is delivering a new API to support a user defined identifier for custom processes and worksteps which will be unique across the Petrel application. Any process/workstep created through Ocean should now implement a unique identifier.
Please refer to:
- Process.UniqueId to define unique identifier for processes
- Workstep.UniqueId to define unique identifier for worksteps.
The new API also offers backward compatibility support for already serialized processes/worksteps and a few changes in the serialization logic. When a legacy project is being opened the old-style ids are automatically replaced by new ids during deserialization.
Best Regards,
Gaelle