HTTP caller - POST to add Cityworks WorkOrder Attachment
I am trying to post an AGOL attachment (i.e. an image) to a Cityworks Work order using the HTTP caller. My goal is to post a unique image to a unique work order (i.e. an image of a sidewalk crack for a sidewalk work order, a pothole image for a pothole work order etc.). The issue starts with my file. I am using AttributeFileWritter to write the file. I use a variable from the feature layer to name my output file (i.e. @Value(WorkorderID).jpeg). This writes to my output directory with no issues. When I go to try and upload this file, when I feed it the PATH + file name + file extension it results in an error “HTTP/FTP Transfer: Failed to open file for resource upload”. When I explicitly “Select” the file it will upload without issues.
My workflow is as follows
I write the image file
I make the call
My body call
This body call is what throws the error. When I add the variable name with extension for the file I want it to upload, it results in the following error “HTTP/FTP Transfer: Failed to open file 'C:\PATH\TO\PICS\WorkOrder_Pictures' for resource upload”.
However when I select the image itself it runs no problem. But this is uploading the same picture to all work orders and not a unique one based on the work order type.
I have also tried various file path manipulations. I have created to create a new attribute with the file name and extension already concatenating, I have tried other name combinations, I have tried temporary files as well all to no avail.
Looking if anyone has had a similar experience. I know there is a similar post but it looks like there was never an official solution.
Page 1 / 1
Hi @afrancio I just tested this out in FME 2023.2 and I am able to dynamically create attachments on work orders. Whether I select a specific file or specify a @Value(WorkOrderId) value for the .jpg name, I am able to run the HTTPCaller and receive the same response from Cityworks.
What version of FME & Cityworks are you using? In your HTTPCaller did you set the MIME Type on the File Upload to image/jpeg? To check this go to Body > Multipart Upload (in the HTTPCaller), click on the three dots in the Value column and then change the MIME Type.
Hi @danminneyatsaf
Thanks for taking the time to respond to my post.
I am using FME form 2023.0.2.1 (20230803 - Build 23339 - WIN64).
I am using Cityworks 17.142.15
Even setting the MIME type as .jpeg as you suggested still produces the error. It seems like it does not want to find my dynamic value. I have even tried to use AttributeCreator to create a new attribute that holds the value of my PATH and Dyanic value + .jpeg extension and still produces the following error.
@afrancio if you check the Rejected port on the HTTPCaller and look at the _error attribute and the _response_body attribute, do you see any additional messages? I’m using Cityworks 23.2 but I don’t expect that would affect how the HTTPCaller runs. I’ll test out FME Form 2023.0.2.1 to verify if there’s an issue/bug.
Are you able to share your workspace with us? This will allow us to reproduce the same steps you’re performing in your workspace which gives us the best chance of reproducing the issue and resolving it for you.
I have uploaded my workspace to the FTP site using “Native computer client” option from the link. My file name is “AF_own_cityworks_WO_Worfklow.fmw”. Please let me know if you see it on your end. Once again thanks for your continue help/support.
The _error message from the Rejected port reads “HTTP/FTP Transfer: Failed to open file 'C:\Path\ to\WorkOrder_Pictures\.jpeg' for resource upload”
The _response_body attribute reads “{"WebServiceRequestId":null,"Value":I{"WorkOrderId":"402","WorkOrderSid":402,"DomainId":1,"ProjectSid":0,"WOTemplateId":"135","WOCustFieldCatId":4,"Unattached":true,"AssetGroup":"Roads","ApplyToEntity":"MUNICIPALRD_SEC","Supervisor":"","RequestedBy":"","Location":"","AcctNum":"","ContractorSid":0,"UpdateMap":true,"LegalBillable":false,"ContrBillable":false,"CycleFrom":2,"CreatedByCycle":false,"SourceWOId":"","TransToWOId":"","Description":"MMS Cracks","Priority":"3","WOXCoordinate":-9999.0,"WOYCoordinate":-9999.0,"WOZCoordinate":-9999.0,"NumDaysBefore":2,"WOAddress":"","MapTemplateName":"","WOMapScale":2,"InitiatedBy":"Francioni, Anthony","InitiateDate":"2024-02-29T14:27:05Z","CycleType":0,"CycleIntervalNum":2,"SubmitTo":"","CycleIntervalUnit":2,"WOClosedBy":"","DateWOClosed":null,"ProjectName":"","DateSubmitTo":null,"SubmitToOpenBy":"","DateSubmitToOpen":null,"FromDate":null,"ProjStartDate":"2024-02-29T14:27:05Z","WorkCompletedBy":"","ProjFinishDate":"2024-03-30T13:27:05Z","DateToBePrinted":"2024-02-27T14:27:05Z","WOOutput":2,"ActualStartDate":null,"ActualFinishDate":null,"MapPage":"","Shop":"HARDTOPMAINTENANCE","Status":"OPEN","Cancel":false,"CancelledBy":"","DateCancelled":null,"ScheduleDate":null,"WOCategory":"ROAD COMPLIANCE","TileNo":"","DatePrinted":null,"Stage":1,"ExpenseType":0,"WOCost":0.0,"WOLaborCost":0.0,"WOMatCost":0.0,"WOEquipCost":0.0,"WOPermitCost":0.0,"CancelReason":"","District":"","Resolution":"","PrimaryContractId":0,"ContractorName":null,"ContractWOId":"","StreetName":"","UnitsAccomplished":-9999.0,"UnitsAccompDesc":"EA","LockedByDesktopUser":"","UnitsAccompDescLock":false,"IsReactive":true,"Effort":0.000,"SupervisorSid":0,"RequestedBySid":0,"InitiatedBySid":115,"SubmitToSid":0,"SubmitToOpenBySid":0,"WorkCompletedBySid":0,"CancelledBySid":0,"ClosedBySid":0,"IsClosed":false,"ActivityZone":null,"InitiatedByApp":"INTERNAL","Facility_Id":null,"Level_Id":null,"ProjectPhaseId":null,"PerformanceBudgetId":null,"Text11":"","Text12":"","Text13":"","Text14":"","Text15":"","Text16":"","Text17":"","Text18":"","Text19":"","Text20":"","Text1":"","Text2":"","Text3":"","Text4":"","Text5":"","Text6":"","Text7":"","Text8":"","Text9":"","Text10":"","Num1":-9999.0,"Num2":-9999.0,"Num3":-9999.0,"Num4":-9999.0,"Num5":-9999.0,"Date1":null,"Date2":null,"Date3":null,"Date4":null,"Date5":null}],"Status":0,"Message":null,"ErrorMessages":,],"WarningMessages":W],"SuccessMessages":S]}”
@afrancio Taking a look at your workspace, the issue could be due to the order of operations when the workspace runs.
Since you’re running the workspace all at once, it could be that the WorkOrderCreator is finishing running before the AttributeFileWriter does and then the HTTPCaller that tries to attach the file to the Work Order but fails to find the .jpeg file since the AttributeFileWriter hasn’t finished running yet.
Try putting your AttributeFileWriter before your WorkOrderCreator and re-run the workspace and see if that works for you. This will ensure that the .jpeg file is created before the HTTPCaller_2 (that attaches the file to the work order) runs. See the screenshot below to see what I’m talking about.
hi @danminneyatsaf
Thanks for taking a look at this.
However when I change the order of operation as you suggested but I still get the same error. I thought the issue may be my file name as the output from the WorkOrder Creator only has the following attributes
address
authentication
entity_type
instance
request_params
response_body
wo_template_id
work_order_id
I even tried to add an Attribute Exposer after the WorkOrderCreator to expose the “DueDate” parameter (which is the dynamic file name I am using to name the file in my AttributeFileWriter). But still producing the following error.
Running in a staggered approach (i.e. run to the work order creator, run the work order creator, then run the HTTP caller) also produces this error.
@afrancio you will need to expose the attribute within the WorkOrderCreator.
To do so, right-click on the WorkOrderCreator and select “Embed”. The transformer should change colour to green. Right-click on the WorkOrderCreator again and select “Edit”. In the WorkOrderCreator tab, double-click on the Input object and select dueDate as an external attribute to expose.
Next, open the AttributeKeeper parameters and select dueDate.
dueDate should get passed through the WorkOrderCreator and be available on its output feature. Hope this helps!
Hi @danminneyatsaf
This finally worked for me! Thank you for the insight and support along the way, its much appreciated.
