HTTP caller - POST to add Cityworks WorkOrder Attachment

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.

If you don’t want to share the workspace publicly on the FME Community you can upload it to our FTP site and I can take a look into it. Instructions on how to upload a file to our FTP site can be found here: https://support.safe.com/s/article/upload-a-file-to-the-safe-software-support-ftp

Hi @danminneyatsaf ,

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":[{"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":[],"SuccessMessages":[]}”

@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.

Hi @danminneyatsaf 

This finally worked for me! Thank you for the insight and support along the way, its much appreciated.