https://pact.io logo
Join Slack
Powered by
We are using BDCT and I'm currently at the state w...
# pactflow
j
We are using BDCT and I'm currently at the state where I want to create some Pact files from our provider side (for the provider self verification results). We already have pytest cases for our Provider RPC endpoints, what would be the recommended way to extend these in order to create a valid Pact file to use in Pactflow?
y
you dont need to use pact for bdct provider self verification. if you are going to. you should just use cdct
where have you seen that you need to create pact files for your provider side
j
Yes this is what I understood as well, I do however need my tests to create some file understood by PactFlow correct? Since we can't use an openAPI file I thought we might be able to modify our pytest cases to create some sort of proof of validation
In the docs it often just mentions 'provider verification results', this is the step that's a bit unclear to me
y
if you aren’t using an OpenAPI document, then you cannot use BDCT in its current state provider verification results is the output of any tests you write to ensure the provider honours the api description. these are your own tests done however you want. we don’t elude to how because they are an infinite number of ways.
are you using json-rpc?
j
Here's a message from one of our backend devs:
We have auto-generated OpenAPI specs, e.g. here.
However they are not 100% valid, and unfortunately can't be, because OpenAPI can't express JSON-RPC endpoints. 😞
Would there be some way around this issue?
y
no sorry, you can’t use bdct
json-rpc isn’t something Pact understands either so one would need to create a Pact plugin to do so
j
Alright, seems we need to go back to the drawing board.. Thank you for the clear answers 🙂
I think Matt sent this to me before: https://docs.pact.io/users/community_corner/adam_cox_interview_may2023 I guess a plugin like that would do the job?
y
yes correct i was just about to paste that link. Adam did indeed create a json rpc aware plugin for use at his company
j
Thank you very much, will talk with the devs and see which route would work best for us
Revisiting this same topic, unfortunately, it's not feasible for us to switch to CBCT, nor do I think we can spend the time making a plugin for Pact. Is there absolutely no way to represent JSON-RPC endpoints in an OAS file, using custom 'x-' properties for example?
m
Late to this thread, sorry.
It looks like JSON-RPC (at least the headers/bodies) can be represented as OpenAPI documents, because from what I can see The answer is “it depends” because it’s transport agnostic, so it somewhat depends on how your HTTP (I think you’re using HTTP?) servers are setup to handle it. I don’t know how hashes in the paths will be accounted for e.g. 
/resource#subResource
because usually hashes are client-only, so you might need to test how this works. The other problem will be the consumer side of this. I’d start with a single OAS document and a basic pact file and see if you can get it to work with BDCT. If not, then yes, back to the drawing board I’m afraid.
If you can elaborate a bit more on the JSON-RPC setup (assuming it’s over HTTP?) then that would help
j
Thank you Matt, and yes we do use HTTP. Currently we use a 
#
in the path (I sent you the 'openAPI' file privately) to make them unique. We did get a working example but only when there's one method per path. So it's really mostly about how to organize the file, I tried using some custom fields but it seems they get removed when Pact does its formatting. Screenshots are from Swagger and from Pact where the 
x-
fields are gone. On FE our current workaround is to tell Pact we called e.g. 
/path#method
, but in reality we called 
/path
with method just in the payload.
m
Ah, interesting. looks like we just don’t render the extensions, but we definitely don’t remove them
is your current approach working? Perhaps we could draft up how it works in the documentation
j
It is working in the sense that we can be fairly sure our integration is correct, since BE's (fake) openAPI spec is code generated, and FE parses this file to implement their Pact tests. Inside PactFlow however it doesn't look so great, because our weird BE spec is throwing lots of errors. Like I mentioned I got it to work beautifully with just one method per path, but I still need to find a workaround for having many methods for a single path.
We're a little bit further down the line, and by now we have attracted the attention from our BE team. They are willing to create Pact tests as well so I think this means we can switch to CBCT and get rid of the flaky fake OAS file. There are some concerns from developers in our company that the switch to CBCT might be too involved, could you confirm that the process is still roughly like this:
Copy code
frontend wants to deploy -> asks pact broker
pact broker -> triggers backend pipeline and waits for result
pact broker -> report back to frontend
frontend -> do actual deployment
Some of the devs are concerned due to some flaky pipelines which might cause significant delays with a procedure like this.
Open in Slack
PreviousNext
Powered by