I am working on sending some additional data for a workday using this endpoint Edit_Worker_Additional_Data. However, it lacks the documentation as what type of data they are expecting, hence, I am getting validation errors. I have tried various combinations but all in vain.
I took some guidance from this question but getting cus namespace error as I don't know where and how he initialized that namespace. Data for the custom field that I want to send:
Custom List
T-Shirt Sizes
Custom Field Type Name
T-Shirt Sizes
Web Service Alias
tShirtSize
List Value Name
Web Service Alias
M - Xs
mXs
M - S
Ms
Given below is the XML request body that I am sending
<soapenv:Body>
<bsvc:Edit_Worker_Additional_Data_Request
xmlns:bsvc="urn:com.workday/bsvc" bsvc:version="v38.1">
<!-- Optional: -->
<bsvc:Business_Process_Parameters>
<!-- Optional: -->
<bsvc:Auto_Complete>true</bsvc:Auto_Complete>
<!-- Optional: -->
<bsvc:Run_Now>true</bsvc:Run_Now>
</bsvc:Business_Process_Parameters>
<bsvc:Worker_Custom_Object_Data>
<bsvc:Effective_Date>2022-11-18</bsvc:Effective_Date>
<bsvc:Worker_Reference bsvc:Descriptor="string">
<!-- Zero or more repetitions: -->
<bsvc:ID bsvc:type="Employee_ID">3671</bsvc:ID>
</bsvc:Worker_Reference>
<bsvc:Business_Object_Additional_Data>
<!-- You may enter ANY elements at this point -->
<bsvc:tShirtSizes>
<bsvc:tShirtSizesField>mXs</bsvc:tShirtSizesField>
</bsvc:tShirtSizes>
</bsvc:Business_Object_Additional_Data>
</bsvc:Worker_Custom_Object_Data>
</bsvc:Edit_Worker_Additional_Data_Request>
</soapenv:Body>
Following are the validation errors that I am getting with different combinations
Invalid Subelement tShirtSizes-urn:com.workday/bsvc for element Effective_Dated_Web_Service_Additional_Data
Invalid Subelement T-Shirt_Sizes-urn:com.workday/bsvc for element Effective_Dated_Web_Service_Additional_Data
I'm not sure if you've already got an answer. It looks like you need the Custom Object name Web Service Alias and the Custom Field Web Service Alias for T Shirt and T Shirt Sizes. Assuming T Shirt is a custom object for the Worker Object Extended. This can be found by someone with appropriate security access in the Workday environment you are trying to make this for. Looks like this is just a custom list which doesn't really provide the context we are looking for.
In Workday search for Custom Object Definitions
Search By Business Process Type
Select Edit Worker Additional Data Event
At this point you may have one or more results (most likely one), but based on context it should be appended by (Effective Dated)
From here one should find what you are looking for.
Here is an example of what this looks like for another custom object
Workday Custom Object Picture
Once you get this information it could be something like this:
<bsvc:Custom Object's Web Service Alias>
<bsvc:Custom Field's Web Service Alias>Whatever Type of Value</bsvc:Custom Field's Web Service Alias>
</bsvc:Custom Object's Web Service Alias>
Keep in mind that the Custom Fields may be of type boolean so it could also look like this:
<bsvc:tShirtSize>
<!--If field is required send else don't-->
<bsvc:mXs>true</bsvc:mXs>
<!--If field is required send else don't-->
<bsvc:Ms>false</bsvc:Ms>
</bsvc:tShirtSize>
Hope this helps!
Related
I am pondering about schema design with regard to explicit vs implicit relation when to...
for example:
in an imaginary schema with 2 custom types author and post, each with several properties, A post type can reference an author in 1 of 2 ways:
explicit: having an Autor type property
implicit: having a scalar value that indirectly points to the author
when designing a shema. what should be my compass in this kind of desicion making?
thanks in advance
There's absolutely no value to the client in only returning the ID of a related resource when you could just expose a field that would return the entire resource. Exposing only the ID will mean the client will have to make subsequent requests to your service to fetch the related resources, instead of being able to fetch the entire data graph in one request.
In the context of other services, like a REST API, it might make sense to only return the ID or URL of a related resource. This is because in those cases, the payload is of a fixed size, so returning every related resource by default can quickly and unnecessarily bloat a response. In GraphQL, however, request payloads are client-driven so this is not a concern -- the client will always get exactly what it asks for. If the client needs only the author's ID, they may still fetch just that field through the author field -- while allowing a more complete Author object to be fetched in other requests or by other clients.
I am developing a series of Slack apps for my workspace, and some of them are meant to interact with the content (messages) delivered by the other apps : extracting content IDs that may be referred to by other messages
A concrete example :
Suppose I have an app A "FindUser" that is capable of giving me the user profile when a slack user types find me#example.com, and it replies in the thread with a formatted view of the user profile
I am developing an app B "EditTags", which basically gives me a right click option with "edit tags" (see Slack's Interactive Components/Actions), the idea being that a user could first ask app A to find a user, and then right click on the reply from App A and click the "edit tags" action given by the other app. What this app B does it actually retrieve the tags for the user mentionned by the previous message from app A, and in another reply to the thread it gives some controls to either delete an existing tag OR it shows a select with autocomplete to add new tags.
The B app needs to retrieve the user ID that the A app mentionned previously. So I need some way to pass that data directly in the slack message. When looking at the examples, slack does not seem to provide a way to add arbitrary "metadata" to a message, am I wrong ? Do you have workaround for this ? I mean I could totally send the user ID say, in the footer, so I can just read the footer, but I was planning to use the footer for something else... Is there a way to pass metadata hrough properties that would be hidden to the end user ?
Although this does not feel relevant, I am building a slack nodeJS app using the node slack sdk (and especially the #slack/interactive-messages package)
For the most part the Slack API does not provide any official means to attach custom data / meta data to messages. But with some simple "hacks" it is still possible. Here is how:
Approach
The basic approach is to use an existing field of the message as container for your data. Obviously you want to pick a field that is not directly linked to Slack functionality.
Some field are not always needed, so you can just use that field as data container. Or if its needed, you can include the functional value of that field along with your custom data in the data container.
For example for message buttons you could use the value field of a button and structure your code in a way that you do not need it in its original function. Usually its sufficient to know which button the user client (via the name field), so the value field is free to be used for your custom data. Or you can include the functional value of your button along with the custom data in a data container (e.g. a JSON string) in that field.
Serialization
All messages are transported through HTTP and mostly encoded as UTF-8 in JSON. So you want to serialize / de-serialize your data accordingly, especially if its binary data. If possible I would recommend to use JSON.
Length
The maximum allowed length of most fields is documented in the official Slack API documentation. e.g. for the value field for message buttons can contain up to 2.000 characters. Keep in mind that you need to consider the length of your data after serialization. e.g. if you convert binary data into Base64 so it can be transported with HTTP you will end up with about 1.33 characters for every byte.
Contents
In general I would recommend to keep your data container as small as possible and not include the actual data, but only IDs. Here are two common approaches:
Include IDs of your data objects and load the actual objects
from a data store when the request is later processed.
Include the ID of server session and when processing the request you
can restore the corresponding server session which contains all data
objects.
In addition you might need to include functional values so that the functionality of the field you are using still works (e.g. value of a menu option, see below)
Implementation
Dialogs
Dialogs provide an official field for custom data called state. Up to 3.000 characters.
Message buttons
For Message buttons you can use the message action fields / value. Up to 2.000 characters. Its also possible to use the name field, but I would advise against it, because the maximum allowed length of that field is not documented.
Message menus
For Message menus you can use the value field of an option or the name field of the menu action.
Usually the value field is the better approach, since you have a documented max length of 2.000 and it gives you more flexibility. However, you will need to combine you custom data with the actual functional value for each option. Also, this will not work for dynamic select elements (like users), where you can not control the value field.
When using the name field note, keep in mind that the maximum allowed length of name is not documented, so you want to keep you data as short as possible. Also, if you want to use more than one menu per attachment you need to include the actual name of the menu into your data container.
Normal message attachments
Normal message attachments do not contain any suitable field to be used as container for custom data, since all fields are linked to Slack functionality.
Technically you could use the fallback field, but only if you are 100% sure that your app is never used on a client that can not display attachments. Otherwise your data will be displayed to the user.
I built two custom components using built-in CQ components. The components' JSP's, along with some custom javascript, have a line like below in order to leverage the built-in components (and their formatting, labels, etc.).
<cq:include path="." resourceType="foundation/components/form/dropdown" />
I have one each of my custom dropdown components on a form. I can mark field A and field B as both being required in their respective components' editor dialog. I can provide required messages so that when either field is blank and the form is submitted, I get a message that the fields are required (with my custom messages). However, what I really want to do is hide or disable field B based on the value supplied in field A. I'm handling this manually via jQuery. However, this of course presents a problem on validation. I want field B to be NOT required when it is hidden/disabled and for it to be required when it is enabled/visible. Since the showing/hiding is done client-side, the server-side validation has know knowledge of the change and still expect a value to be provided for field B.
I'm been trying to poke around in the CQ Widgets API to find if there is something I can do on the client side to set/unset the required property so that when the form gets posted it is handled correctly. I'm guessing that there isn't since the validation seems to be happening on post instead of client-side.
Any ideas/thoughts/options?
It turns out that the link from my comment gave me the idea that I can have custom server-side validation for my form, I just wasn't sure how to connect it to the field. It turns out that all I had to do was create a servervalidation.jsp file in my "B" component. CQ will see the servervalidation.jsp and automatically invoke it for my custom component.
I was then able to examine the submitted value of field "A" (by getting the parameter from the request object) and doing some other custom logic for my needs.
I was then able to optionally do this:
FieldDescription field = FieldHelper.getConstraintFieldDescription(slingRequest);
FieldHelper.checkRequired(slingRequest, field);
I am in reference to the following method from BindingResult:
BindingResult.html#resolveMessageCodes(java.lang.String, java.lang.String)
I am trying to figure out the difference between an error code and a message code. Can someone please provide an example, especially one that would illustrate why there could be several message codes for a given error code?
Because web applications are internationalized, when you reject an object and want to have a message displayed for it, you don't use a hardcoded text because that will show the same no matter the language.
Instead, you specify an error code that later server as a key to retrieving the proper message from the bundles (and now the error code is a message code from the point of view of the method that must find the proper message text).
Your error code resolves to more message codes because Spring (based on the implementation) adds some additional ones for you. Here is a snippet from the Spring documentation:
[...] What error codes it registers is determined by the MessageCodesResolver that is used. By default, the DefaultMessageCodesResolver is used, which for example not only registers a message with the code you gave, but also messages that include the field name you passed to the reject method. So in case you reject a field using rejectValue("age", "too.darn.old"), apart from the too.darn.old code, Spring will also register too.darn.old.age and too.darn.old.age.int (so the first will include the field name and the second will include the type of the field); this is done as a convenience to aid developers in targeting error messages and suchlike. [...]
The last statement is the reason there are more message codes, to have control on the message that is displayed to the user, from a generic one (e.g. "Value required") to a more specific one given the context (e.g. "A value is required for field XXX").
The javadoc for DefaultMessageCodesResolver explains it further and gives an example:
For example, in case of code "typeMismatch", object name "user", field "age":
try "typeMismatch.user.age"
try "typeMismatch.age"
try "typeMismatch.int"
try "typeMismatch"
This resolution algorithm thus can be leveraged for example to show specific messages for binding errors like "required" and "typeMismatch":
at the object + field level ("age" field, but only on "user");
at the field level (all "age" fields, no matter which object name);
or at the general level (all fields, on any object).
I want to build a typical mvc app for CRUD of simple items, the api s should be RESTful. The catch here is, that i have a large pallete of items that needs to be initialized. On the server side those items are defined as java beans and the corresponding create form for the item is dynamically created from the field information(data type, validation constraints etc) harvested from the bean.
I am new to REST and just read up about how the urls should be nouns defining the resource and action specified by HTTP verb. In that perspective how to model something like
.../client/showForm?type=xyz from non RESTful way to RESTful one ?? My intention here is to tell the server to dynamically construct and send back a CREATE form for client of type xyz. The obvious problem with url i mentioned above is that it specifies action in the url which, from what i have read, makes it non RESTful.
When I think of REST, I think of resources. I think of data. In other words, I don't think of REST as being something that I would typically use to retrieve a form, which is a user interface component.
REST is an architectural style that is used to identify a resource on a server using a uniform resource identifier, or URI. Additionally, actions performed on those resources identified by the URI are determined based on the specific HTTP Method used in the request: GET, POST, PUT, DELETE, etc.
Thus, let's say you have a Client object. That client object might have the following properties:
Name
Location
AccountNumber
If I wanted to retrieve the data for a single client, I might use the following URI:
GET /client/xyz/ # xyx is the accountnumber used to identify the client.
I would use a GET method, since REST describes GET as being the method to use when retrieving data from the server.
The data could theoretically be returned in HTML, since REST is not a standard but more like a series of flexible guidelines; however, to really decouple my data from my user interface, I would choose to use something platform independent like JSON or XML to represent the data.
Next, when adding a client to the collection on the server, I would use the /client/ URI pattern, but I would use the HTTP Method POST, which is used when adding a resource to a collection on the server.
# Pass the data as JSON to the server and tell the server to add the client to the
# collection
POST /client/ {"accountnumber":"abc" , "Name" : "Jones" , "Location" : "Florida"}
If I were to modify an existing record on the server or replace it, I would most likely use the HTTP Method PUT, since REST guidelines say that PUT should be used if repeating the same operation repeatedly would not change the state of the server.
# Replace the client abc with a new resource
PUT /client/abc/ {"accountnumber":"abc" , "Name" : "Bob Jones" , "Location" : "Florida"}
The general idea behind REST is that it is used to identify a resource and then take action on that resource based on what HTTP Method is used.
If you insist on coupling your data with your view, one way accomplish this and retrieve the actual form, with the client data, could be to represent the form as a resource itself:
GET /client/abc/htmlform/
This URL would of course return your client data for client abc, but in an HTML form that would be rendered by the browser.
While my style of coding utilizes data transports such as JSON or XML to abstract and separate my data from my view, you could very well transport that data as HTML. However, the advantage of using JSON or XML is that your RESTful API becomes platform independent. If you ever expand your API to where other developers wish to consume it, they can do so, regardless of what specific platform or programming language they are using. In other words, the API could be used my PHP, Java, C#, Python, Ruby, or Perl developers.
In other words, any language or platform that can make HTTP requests and can send GET, POST, PUT, DELETE requests can be used to extend or build upon your API. This is the true advantage of REST.
For more information on setting up your controllers to use REST with Spring MVC, see this question. Additionally, check out the Spring MVC Documentation for more information.
Also, if you haven't checked out the Wikipedia article on REST, I strongly encourage you to do so. Finally, another good, classic read on REST is How I Explained REST To My Wife. Enjoy.